-
FEATURED COMPONENTS
First time here? Check out the FAQ!
Good day to all,
I am watching with great interest the evolution of the binder in ZK 6 and i would like to share some thoughts.
About 12 years ago i was working in a quite big project written in Cobol (yes! Cobol!). Microfocus (the cobol vendor) provided at that time a tool for the construction of the user interface called "Dialog System". The "Dialog System" was actually a GUI framework which at that time was quite evolutionary, at least for the cobol community. Dialog system was an MVC based framework. It had each own declarative language (like XML) and each own data binding mechanism. The developer had the ability to test the controller without affecting the GUI layer (i.e view) at all.
At first, working with this technology was very smooth and promising. It gave to our team the ability to standardize the production and the testing procedures. Everything was fine as long as we had to implement relatively simple CRUD forms. The problems started to appear along with requirements for more advanced functionality. Dialog System provided a set of predefined events (e.g. before update, after update, initialize etc) to allow the developer to do more advanced things. Triggering an event caused the execution of the desired code which in turn could trigger another event and then notify the view layer to update some components which in turn could trigger another event and so on... Unfortunately the whole thing turned out to be a maintenance nightmare. In case we had to add a significant amount of functionality in an existing complicated form it would be better to rewrite it from scratch.
Few years later it was obvious that the Dialog System was practically past. Both micorofocus and developers abandoned it.
The reason i am telling this story is not to say that the new features coming with the ZK 6 binder are not good. The new bind technology is promising but honestly i don't think that the following XML code is maintainable:
@bind(vm.selected.description, save=vm.selected.description before 'saveOrder') @bind(not empty vm.deleteMessage)
Don't forget also that the above code is just strings. No advance search, no reference search, no type matching. Just plain string declarations. I remember myself going mad trying to find for three hours which event was causing a bug in a quite complicated form.
just some thoughts.
brgds to all
/costas
Hello all!,
I am a contributor(REM).
I also agree to cyiannoulis.
Codes produced by ZK 6 binder are too tedious and not beautiful,I think.
It should be more nearly intuitive and should be simple.
I think that nobody used from the complicatedness when ZK had started from ZK 6 binder.
Hi,
i also agree with cyiannoulis. The databindingcode looks "not simple". Of course the are many new features (forms!!, contraints, declare the viewmodel...).
However, i always avoid unchecked code (first check at runtime!!).
I think most code looks like this:
old style:
<listcell label="@{person.address}" /> <listcell label="@{person.account, converter='org.zkforge.converters.ColorNumberCustom'}"/> <listcell label="@{person.birthdate, converter='org.zkforge.converters.DateUser'}"/> <listcell label="@{person.color}" />
<listcell label="@bind(person.address)" /> <listcell label="@bind(person.account) @converter('org.zkforge.converters.ColorNumberCustom')"/> <listcell label="@bind(person.birthdate) @converter(${DateUserConverter}')"/> <<< Converter could be EL i.e. Spring should be possible <listcell label="@bind(person.color)"/>
But this lines like this are powerful, but looks too tedious.
<grid self="@form(id='fx', load=vm.selected, save={vm.selected before 'update', vm.newAlbum before 'add'})">
<button onClick="@bind('add')" label="Add"/>
comma separate between parameters <ok>, quote or not to quote?, sometimes multipart-parameters "before update"....
@bind=databind, onClick=@bind=event?
But here my personal nr. 1 request (the same as ZK 5):
ZK docs wrote:
>> Same Java style annotation expression in zul: The new ZK annotation is consistent with Java's annotation style.
>> If you know the Java style, you know the ZK Style.
In java i could press ctrl + space (inside the annoation in eclipse) - and i'll see the possible parameters.
I would like to see this feature (and more like syntax check and autocompletion) in the zul-editor.
/Robert
The autocomplete feature is good. Any other suggestion about how to make it easier to read and maintain?
@Robert, it is OK to use a class in new data binding's annotations, but we generally want to hide the concept of classes/events from UI designers. For example, we use logic names for the converters in the small talks.
The new binder utilize the EL 2.2 expression syntax that is good or bad. Good with great flexibility (unlike databinding version 1 which allows getters and setters only). Bad as you guys said, it makes expression's look complicated and harder to maintain.
BTW, no need to enclose ${...} around expression. The EL engine will fetch the object from Spring for you per the variable name.
<listcell label="@bind(person.birthdate) @converter(myDateUserConverter)"></listcell>
Asked: 2011-11-15 09:51:03 +0800
Seen: 689 times
Last updated: Nov 17 '11