cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claas Thiele <cthi...@ct42.de>
Subject Re: CForms-XUL project information
Date Thu, 16 Jun 2005 11:02:48 GMT
Hi,

I think the proposed way using XUL is more different from CForms 
principles than described in the proposal.

It is possible to use XUL in the way described in the proposal but this 
would not be the way the advantages of XUL can used.

XUL will separate style, layout description, and dynamic content by its own.

A XUL file is the layout description and will normally remain static, 
can be cached by the client therefore it will be loaded only once on 
application startup.

Styling is done using CSS in a more cleaner and powerful way as it is 
known for HTML.

Dynamic content is sent to the client as RDF and weaved in using XUL 
templates. Dynamic content is requested from the server for a widget, 
not for a page. So XUL is comparable to an HTML application using 
iFrames and layers.

For i18n XML entities are used.

A good way to use XUL is moving logic (content invalidation, input 
validation, ..) to the client and implementing it in JavaScript. Doing 
this XUL will be the basis for a Rich Client Architecture.


Following this 'XUl principles' it has a huge impact of the CForms strategy:
- The one and only transformation to be done seems to be the 
transformation of dynamic content to RDF (sometimes a crucial thing, 
Jörg can tell you something about that)
- It should be possible to mix client side and server side input 
validation (is this already done in CForms?)
- While XUL will not update the whole page it is more a multiform 
approach. This will have an impact on form handling.
- Instead of using the i18n transformer the xml entity approach of XUL 
should be used. I don't like it, but otherwise it is very difficult to 
use XUL files as static layout description.

Using XUL as it is made for will enable you to build complex user 
interfaces with very good usability and more performant than an HTML 
based web application. This can be reached with the proposed approach 
partially only.


Regards

Claas Thiele


Mime
View raw message