User interface form state and interaction with model advice

Advice of the week:

Separate form bean and core model state in more complicated (not naive) user interface related use cases. Propagate changes using events and sensible messaging.

Little real life story:

I have used two different frameworks in two production systems with naive auto binding controls with model objects. In both cases controls were changing almost directly state of underlying model entities. It's good for fast prototypes, but not for production demands and interaction with real users. Creating simple workarounds was good enough, but caused strange quirks in displaying actual state. Some fraction of users were loosing their confidence in system reliability, and called for support. The problem was fixed, by redesigning some UI controls and model entities interaction.

I have used Wicket for small web application

More than week ago I have started implementing first module for Medical Diagnostic Expert System. It's quite simple application for manual data entry and editing. There is one catch - forms have to be flexible in some way and dynamically configurable. The whole project will work as web application, so data entry editor will work in that way too.

As this is the new fresh project I have possibility to use the newest Java features and frameworks. The multi tier architecture application will use Spring for easy separation of concerns between layers. That plus JPA on top of Hibernate should be sufficient for future development of modules and expansions (the final project boundary is blurry).

I thought about using Spring MVC framework, but after little research I decided to use Wicket, to set up user interface. Wicket is using view component model, with main page component containing other components and controls with event handlers. Binding controls is made by marking special wicket attributes in html template. Additional markup is not intrusive, so even raw html template viewed in web browser is looking good (sounds like Tapestry). The basic ideas are similar to that used in ASP.NET. Developing in Wicket is more Java code centric than in other popular frameworks, with clean separation of html template design.

For quick start up I have used QWicket generated application template and tailored it to work with JPA and my core module. Application should work under Postresql database, but for easy of deployment of prototype for testing purposes I stayed with preconfigured HSQLDB. Switching back to Postgres is just as easy, as changing few lines in properties file.

I'm unexperienced Wicket user but development goes quite smooth. Using documentation, tutorials and books is really helpful at that stage. As far so good. I'm finishing UI prototype and can concentrate now on implementing core module functionalities.

Younger programming languages and frameworks are better

I have short talk with young student of Computer Science. He said he prefers .NET framework and C# more than Java, because Java seems outdated. I've seen those kind of preferences for some time in new generation of young programmers. I've asked what makes Java so outdated. He said about first release year (sic!), and mess in Java libraries, legacy API and so on. I've no time to ask for more details, but many of those pros and cons come probably from rumors and hypes. Good point for .NET marketing.

Younger programming languages and frameworks are potentially better. It's true for most popular (chosen by ,majority so in some way best) languages supported by community and commerce. Standing on the shoulders of existing giants - in that case language frameworks, gives better opportunity to make better API and add more practical features. New languages and frameworks are addressing most popular trends for its time (like WEB 2.0 and AJAX now). Other possible positive outcome would be cutting of all legacy code (good and bad one), and start everything from scratch, that would tend to include new ideas. All that needs many people, hours of work, and money.

So taking that assumptions and having big support - about every 10 (5?) years it would allow to produce new "cool" language that young generation of programmers will choose.

What is the important thing for developers? It's better to be open for new ideas and be ready for changes. What is good tool for work today, would be old in next 10 years.

Java XML object binding libraries

I have to implement mapping between some domain model object and xml document representation. It's actually working production application. Xml schema could be suited to needs of current application. I'm thinking about two free/open source libraries.

Sun promotes Java add-in support for JAXB standard. It looks heavier, and has harder initial learning curve. Last implementation of JAXB 2.0+ gives tools (lek automatic class generation) and aids to simplify development (annotation based mapping definition). So JAXB as officially supported standard should gain more user base.

The good and tested third party solution is JXM (Java XML Mapping). It's default configuration allows fast implementation and mapping of desired object structures. You only have to keep standard node and attribute names, that is right if you are designing XML from scratch using "java code centric" approach. Other possibilities are also enabled by adding some marshaling/unmarshaling code.

As Blogger.com added polling feature, I've posted poll, so readers could give opinion about their favorite XML/object mapping Java library.