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
