Aranea Blog

It’s been awhile but there are also good excuses for the delay! The Aranea-MVC 2.0 work in progress is approaching its end. The changes in the 2.0 version range from the seen to the unseen, in other words, the entire code base has been updated, somewhere refactored, and poked with new features to make 2.0 branch more developer and client friendly. The release candidate is quite stable, so go ahead and try it out! And if you notice something that should be better in the final release, write us about it! Hope to get some feedback about where things could be better. The final release should then included suggestions from feedback and become available somewhere in January depending on the amount of feedbacks.

What’s New in Aranea 2.0

The biggest shift from Aranea MVC 1.2 to Aranea 2.0 lies in code updates to meet Java 1.5.0. Basically all Aranea source code is now based on Java 5.0 and makes use of its features. Therefore, in order to meet and take advantage of these features, in some places were also more changed (concerning mostly method and constructor signatures).

Another part that was heavily refactored, were Aranea scripts. Here, the architecture was redesigned to meet the JavaScript world. The structure of object in memory is more compact (all under common namespace: window.Aranea). Also, a lot of getters and setters were removed when they contained no complex functionality. All scripts data is now stored under Aranea.Data namespace as properties. In addition, Aranea has now more flexible support for JavaScript events. It takes advantage of Prototype’s custom events support using document.observe([eventName], [callback]). Aranea 2.0 scripts come with support for following events: aranea:loaded, aranea:beforeEvent, aranea:updated, aranea:afterEvent, aranea:unloaded. The first and last event are always executed through client navigation. Others are executed only when update regions and AJAX requests are used.

In Aranea forms components, the biggest change went through SelectControl. Because the control was quite rigid to handle and yet widely used, the way the control holds its inner data was basically re-implemented. Now, for defining SelectControl data, no conversion into DisplayItems has to be done anymore! SelectControl just needs to know the type of data the control will hold, and after that, it just takes (a list of) items as Java objects (beans) that match the type. The catch is that the SelectControl needs to know the properties of the beans that will correspond to the label and to the value of the select item. That SelectControl creation part can also be handled by custom subclasses, to make it even more easier.

An additional good news that comes with new SelectControls (of course, including MultiSelectControls) is that no one needs to define converters anymore to get the bean (as a user-selected value) back from the list! To make it possible, the data type of the form element must be the type of the SelectControl item. To illustrate it, when the item type is CustomBean, then the form element should be defined like this:

formWidget.addFormElement("id", "label",
    new SelectControl(CustomBean.class, "label", "value"),
    new Data(CustomBean.class));

(Project should consider creating custom Data subclasses to simplify creating custom SelectControl’s and Data’s for specific data types.)

To continue with the previous code sample, notice that now formWidget.getValueByFullName("id") returns either a null or an instance of CustomBean.

BIG changes in Aranea MVC 2.0 since Aranea MVC 1.2 branch

All code base updated to use JDK 5.0 new features

1. Generics used where possible
2. Varargs used where possible
3. Autoboxing used where possible

Aranea scripts refactored. Main changes include:

1. All Aranea methods and data now under window.Aranea namespace
2. All data stored under Aranea.Data namespace as properties
3. Logging separated into separated namespace: Aranea.Logger. By default, logging is off.
4. Aranea.Page (previously AraneaPage) is not a class anymore but an object!
5. No more possible to use araneaPage() or _ap unless defined in custom scripts
6. The script file aranea-locale.js was removed. All the necessary code from the file was refactored and placed into aranea.js script file.
7. Aranea.KB was renamed to Aranea.Keyboard and was mostly refactored. Aranea.Keyboard.registerKeypressHandler(...) supports both key-code (e.g. 13) and key-combo string (e.g. ‘ctrl+shift+a’).
8. New ways to react to different events. Now is based on Prototype event-system: document.observe([eventName], [callback]), where eventName can be aranea:loaded, aranea:beforeEvent, aranea:updated, aranea:afterEvent, aranea:unloaded.
9. Aranea now includes up-do-date scripts, including Prototype 1.6.1, which is more suitable for old browsers that may have memory leaks. Now Aranea MVC also takes advantage of these new Prototype features in order to help to avoid memory leaks in browsers.

SelectControl and MultiSelectControl refactored to be able accept Java beans as select items

1. *SelectControl must be provided bean properties for retrieving the select item label and value from the bean
2. *SelectControl can be given labels and values without providing them as beans (when the bean label and value properties are writable)
3. The *SelectControl that accepts DisplayItem’s as select items is named DefaultSelectControl (DefaultMultiSelectControl)
4. DisplayItem was also refactored to meet the new needs
5. Now *SelectControls have support for grouping select items.

ListSqlHelper changes. Modified BaseListSqlHelper to simplify helper inner logic:

1. Now full query strings are created in separate methods (no need to check class variables to see if they’re already defined, to override them). New methods include createItemRangeQuery(...), createCountQuery(...), getItemRangeQueryParams(...), getCountQueryParams(...), addCountStatement*Param(...). Also moved many methods, that subclasses had to implement, to the BaseListSqlHelper class.
2. Due to changes in how queries are composed, other implementations of *ListSqlQuery were also updated.
3. Added JPAListSqlHelper to simplify list queries with JPA (uses JPA only, and does not parse result-set).

Other changes

1. Updated the Ivy dependecy file to meet new and updated dependencies
2. BeanUtil was refactored. If a bean property as read/write method is not found, a class field that matches property will be used. Also, public methods accept both simple and nested properties.
3. Every where an ID (component, widget, event, action, etc ID) was passed on, the ID data type was changed from Object to String (where it was not already a String) because the actual ID value was already a String value.
4. StandardLocalizationFilterService and MessageUtil methods accept varargs where applicable. When default message is also provided, it must right after the original message and right before parameters to the first message.
5. MessageContext (StandardMessagingFilterWidget) now accepts parameters to the message. The MessageContext messages are now resolved before rendering!

TO BE UPDATED SOON TO INCLUDE ALL OTHER CHANGES AS WELL

This entry was posted on Tuesday, December 8th, 2009 at 4:44 am and is filed under Devel, News. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.