cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Christophe Kermagoret <...@babelobjects.com>
Subject Re: E-CRUD Design Pattern
Date Fri, 16 Sep 2005 10:23:47 GMT
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: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
> 


-- 

Jean-Christophe Kermagoret
jck@BabelObjects.Com



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message