Thomas,
Thanks for your feedback

I say there is a mix, but there is not. It's a mistake (shame on me). The only ft tag I use is a submit widget.

I start from the principle that the template must reflect the structure (so the binding) of the data the user is editing (or searching). So I deduce from the meta-binding file the form template. In fact, the meta-binding file is almost a binding file (submit ft:widget exception). I also use fi:styling in meta-widgets because I think it's totally generic : it is almost like a validation rule (for email, date).

The templating is done through xslt only. Nothing in the metabind.xml file.

To use meta-information to describe the forms is interesting but I'm afraid to have a lot of specificities, and I would like to have generic forms, that may be heavily reused.

Your description is very interesting, I think there will have a lot to learn from each other by sharing all this.

How did you implement your solution ? Java, javaflow, xslt ?

I tried to do almost everything with xslt (and a little javascript), and benefit the natural cocoon cache to avoid regeneration. Like Cocoon is a perfect REST platform, this CRUD solution is a kind of web service.

There are a lot of things to do (GUI builder - to do, portlet integration - already done, inter portlet communication - already done, ...)

Idem for the list generation...

There is also the need to share things with others projects like daisy, hippo, lenya or specific project like xreporter. We all develop our own CRUD and list generation tool.

Well, a lot of work. It's the goal of the bluexml.org project I set up a few months ago and come back to work after holidays is time for new resolution !!!

Jean-Christophe

Thomas Lutz a écrit :
Jean-Christophe Kermagoret wrote:

There might be some interesting code and documentation (I hope :-)


Great work !


Your discussion is welcome, and, I will say more, awaited with great enthousiasm :-)


I didn't have too much time to have a closer look at it yet, but :-), one remark to the FormGeneration pattern:

Are you sure it's useful to mix up binding and template ? In fact one of the most wanted CForms features (at least for me) is the clear separation of definition, binding, presentation and data. Presentation may change during the lifetime of a webapp. New designs, usability improvements, maybe some sort of a GUI modeler for the user, but this changes usually will not touch data binding.

I/We use a slightly different approach:

Metadata (from database)
|
v
Metadata2FormDef.xsl + Metadata2FormBinding.xsl + Metadata2FormTemplate.xsl
|
v
FormDef + FormBinding + FormTemplate

This conversion process is handled by some pipelines, which
-first check wether there are "pregenerated" form files
-if there are no files ask the db layer for metadata, and do the transformation

This way there is one source for all three form files, and in fact I have to care only about metadata and layout, at least for the standard CRUD forms...

regards,
tom

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



--

Jean-Christophe Kermagoret
[EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to