Tuesday 8 June 2010

User interface: XForms on client, pipelines on server

XForms is a really nice standard. From upper level XForms act as a web service(s) client (both SOAP and REST) - it gets data from a web service, allows user to manipulate it and sends data back to a web service. So we've got a standard browser based UI acting as a web service client. No AJAX needed to program.

Inside XForms has clear model-view-controller separation, provides schema based validations & etc. It is possible to produce default XForms from XML metadata for example.

Browser support

XForms is a part of XHTML 2.0 standard, so sooner or later it will be available in any browser out of the box.
Currently only Mozilla provides good implementation as an add-on, which is acceptable for intranet applications, where you can require users to have it.

For other cases you can can transform your XHTML+XForms to XHTML+AJAX using XSLTForms as a temporary solution.

Produce pages with pipelines

Remember the hell of JSP-JSF, taglibs, custom tags, hidden or direct AJAX usage, binding POJOs... Numerous appearing libraries, their complication, learning curves...
And main problem - JSP pages turns into some history of everything. To separate styling for example you need to make own tags, which is a pain.

I'd rather forget it and use pipelines using Apache Cocoon:
  • Static skeletons of pages with XForms.
  • Fill them with dynamic data (but better would be use XForms to query data directly)
  • Finally apply styling and other whole-site functionality to all pages in one place.
  • And you still have freedom of Java-based controller if you need it.
  • You can go further, for example produce XForms and pages from metadata.
Main advantage is simplicity and separation of different concerns - content management, data access, styling and other features.
Special joy here is that you always can use appropriate tool in your hands - operate XML data with XSLT, query it with XQuery, implement controller logic in Java. And you can always go a meta-level up if you need it. You just handle more complexity at lower development cost.

No comments:

Post a Comment