Before I show the SLOC comparison, I need to give a brief introduction of the little demo program that I wrote. The program is a GUI to show various capabilities of the Address package, which has a service tier and DAO implementations behind it. The Address package provides a meta-data driven way of managing address records (see here for the data model). The concerned application here is only the GUI portion. The GUI has the following screens (left=ZK, right=GWT):
CRUD
This screen is used for Create, Retrieve, Update and Delete (CRUD) of the Address records from/to the database.
Find
This screen is used to call the corresponding Address services to find addresses either by keywords or by location.
Compare
This screen is used to call the corresponding Address services to compare two given Address records. Note that the ZK implementation supports drag-and-drop - i.e. I can drag a row from the list of addresses and drop it onto the text box and the text box will be populated with the content of the address (as a string). On the other hand, the GWT implementation does not support DnD because at the time of writing it, GWT-Ext did not support this kind of DnD yet (and I am not about to rewrite it using new version of GWT-Ext now considering Sanjiv has left the project... but that's another story).
Preferences
This screen is used to manage user preferences of the GUI application. Cookies are used as the storage.
In my SLOC count, I divided the source code into the following groups:
- Main View - this includes the main screens: CRUD, Find and Compare tab panels.
- Preference View - the user preference window
- Model/Controller - the code behind the screen components, including models, event handlers, interaction with the service tier, helper/utilities
- Splasher - this is the Splasher screen displayed at the beginning of the application. Only ZK version has implemented this (using
index.zuland automatically forwarding to the main view after initialising the Address service); other versions do not have this screen.
Note that in ZK, all the views are a result of drag-and-drop from the components palette with modifications by hand.
The physical and logical SLOC counts are shown below.
The results speak for themselves.
UPDATE [2008-12-08]:
- The GWT implementation source code can be found here: Address_gwt.zip
- The ZK implementation source code can be found here: Address_zk.rar
7 comments:
any chance of posting the code?
The ZK source code can be found here.
The GWT one was done a year ago and I will have to dig it up from my backup drive. I will upload it shortly.
Note that the source code is the GUI only (the code used for the SLOC count) without the service and data tiers.
cheers
romen
thanks romen for putting the ZK source there. the reason i wanted to compare is to see whether i felt that either one was more or less maintainable. i find gwt better in this regard because i like using Java rather than XML. also -- for me a couple of hundred lines difference might be a drop in the ocean as long as it is maintainable.
Cheers,
Andrew
p.s. I just have to find something in linux that can unpack rar files now ;-)
ok, i've unpacked it. did you have to write the 251+196 lines of zs and zul? If so, surely that's a big loss relative to keeping it all in java with GWT?
or is the .zs autogenerated from Java? It sort of looks like Java anyway. I can't find the .zs code in any of your .java files. how do you check this code?
am very interested to see the gwt-ext example now.
Cheers,
Andrew
Hi Andrew
The zul files are created using the ZK Studio by DnD from its components palette. Then I hand tailored some of the components - e.g. specifying width, align. I initially created a single Address.zul file that contained everything, then I refactored out the 3 tab panels into their own zul files and have them 'included' in the main Address.zul to make things more maintainable.
The .zs files are created by hand. I could avoid using zscript and use Java classes for all of them. But zscript is a lot shorter to write and can achieve the same with less effort, e.g. zscript has access to many implicit objects and all screen components directly; with Java you can also get them by traversing the object graph using ZK APIs (like in GWT).
In terms of SLOC counts, what matters is not the absolute number since the application is quite simple. It is the relative number among the different frameworks that matters. e.g. the trend that I can see from the graphs is that pure Java language based frameworks tend to have more lines of code. This is not surprising because Java is a verbose language.
Also, I did not try to optimise the code further for either implementation, which can reduce the code count. (e.g. I should have merged the retrieve() and refresh() functions to make them one).
One drawback of ZK Studio is that it does not support code completion properly - I hope they add it in v1.0.
One thing I like about ZK is the simplicity and flexibility - you don't have to do much and it just produce the result that you wanted; and you can always tweak it if you want to. A good example of this is how the List works with its model and renderer. It has the similar concept as contentProvider and labelProviders in JFace, yet so much simpler and more flexible (especially demonstrated by the renderer class).
By the way, I am no ZK expert. I only started playing it 3 weeks ago.
cheers
romen
"One thing I like about ZK is the simplicity and flexibility"
To be honest, the ZK stuff looks better than I thought it would. Does the Zscript turn into Javascript on the client?
Also, how do you find the widgets in ZK compared to something like EXT-GWT or SmartGWT? ZK seems to be missing arbitrary moveable windows. Perhaps they aren't really too useful in a web-app anyway...
Andrew
No, the zscript does not turn into javascript. They are actually executed on the server. That is why ZK calls itself 'server-centric' as opposed to GWT's client-centric approach.
I quite like client-centric approach - makes the application more responsive. However, the price to pay in GWT is the extra work: GWT-RPC implementation of the AddressService, the DTOs and their marshalling/unmarshalling code... that is one reason why GWT SLOC count is so high.
I prefer a combination of serve-centric and client-centric approach: maybe the developer can specify the behaviour? e.g. for the onClick() of my About button (which shows a static copyright dialog box) I want to run as client-centric; for the Retrieve button, I want to run as server-centric...
LnF and layout wise, I feel that ZK is more appealing and easier than GWT-EXT. ZK does have movable windows and dialog boxes. I have not tried SmartGWT, but looking at the demo, it seams that SmartGWT (or SmartClient) has richer widgets. I will give SmartGWT a try later.
cheers
romen
Post a Comment