You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Jean-Christophe Kermagoret <jc...@babelobjects.com> on 2005/09/16 10:48:37 UTC
E-CRUD Design Pattern
Hello,
For those who are interested, I uploaded a few documentation in the wiki
about the E-CRUD Design Pattern.
It is available from the Wiki Cocoon Frontpage in :
* http://wiki.apache.org/cocoon/,
or directly in :
* http://wiki.apache.org/cocoon/DesignPattern/Overview
There might be some interesting code and documentation (I hope :-)
Your discussion is welcome, and, I will say more, awaited with great
enthousiasm :-)
It's a work in progress. If you have any question, or any remark or
addition, don't hesitate to tell me, I will (or You may) correct it
immediately.
Jean-Christophe
--
BlueXML
Jean-Christophe Kermagoret
Directeur associé
06.08.56.83.80
jck@bluexml.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: E-CRUD Design Pattern
Posted by Marc Salvetti <ma...@notremanou.net>.
Jean-Christophe Kermagoret a écrit :
>
> Yes,it's a great idea.
>
thanks :)
> Have you got an overview about your project's technical implementation
> (architecture, ...) ? Where may I download it to have a look ?
>
i'll send you a personal mail with ftp accout
> PS: do you work with Franck Touch ?
>
No, i nearly worked with him trough ;)
> Marc Salvetti a écrit :
>
>> Thanks for the great work christophe, it's a really interesting
>> solution.
>> As many, i done something myself as an exercise that you may use.
>> I designed a very small webapp with a few basic and probably reusable
>> features like gui for user/group managment and gui for
>> catalogues/messages managment, separation between sitemaps (general,
>> data, backoffice) and a styling pattern that uses extensively css to
>> separate design from logical structure. I think my solution for crud
>> is far from good, but maybe you'd be interesting in seeing the code
>> and maybe taking a few ideas ?
>>
>> Marc
>>
>> Jean-Christophe Kermagoret a écrit :
>>
>>> Hello,
>>>
>>> For those who are interested, I uploaded a few documentation in the
>>> wiki about the E-CRUD Design Pattern.
>>>
>>> It is available from the Wiki Cocoon Frontpage in :
>>> * http://wiki.apache.org/cocoon/,
>>>
>>> or directly in :
>>> * http://wiki.apache.org/cocoon/DesignPattern/Overview
>>>
>>> There might be some interesting code and documentation (I hope :-)
>>>
>>> Your discussion is welcome, and, I will say more, awaited with great
>>> enthousiasm :-)
>>>
>>> It's a work in progress. If you have any question, or any remark or
>>> addition, don't hesitate to tell me, I will (or You may) correct it
>>> immediately.
>>>
>>> Jean-Christophe
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>> For additional commands, e-mail: users-help@cocoon.apache.org
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: E-CRUD Design Pattern
Posted by Jean-Christophe Kermagoret <jc...@babelobjects.com>.
Yes,it's a great idea.
Have you got an overview about your project's technical implementation
(architecture, ...) ? Where may I download it to have a look ?
PS: do you work with Franck Touch ?
Marc Salvetti a écrit :
> Thanks for the great work christophe, it's a really interesting solution.
> As many, i done something myself as an exercise that you may use.
> I designed a very small webapp with a few basic and probably reusable
> features like gui for user/group managment and gui for
> catalogues/messages managment, separation between sitemaps (general,
> data, backoffice) and a styling pattern that uses extensively css to
> separate design from logical structure. I think my solution for crud is
> far from good, but maybe you'd be interesting in seeing the code and
> maybe taking a few ideas ?
>
> Marc
>
> Jean-Christophe Kermagoret a écrit :
>
>> Hello,
>>
>> For those who are interested, I uploaded a few documentation in the
>> wiki about the E-CRUD Design Pattern.
>>
>> It is available from the Wiki Cocoon Frontpage in :
>> * http://wiki.apache.org/cocoon/,
>>
>> or directly in :
>> * http://wiki.apache.org/cocoon/DesignPattern/Overview
>>
>> There might be some interesting code and documentation (I hope :-)
>>
>> Your discussion is welcome, and, I will say more, awaited with great
>> enthousiasm :-)
>>
>> It's a work in progress. If you have any question, or any remark or
>> addition, don't hesitate to tell me, I will (or You may) correct it
>> immediately.
>>
>> Jean-Christophe
>>
>
> ---------------------------------------------------------------------
> 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
Re: E-CRUD Design Pattern
Posted by Marc Salvetti <ma...@notremanou.net>.
Thanks for the great work christophe, it's a really interesting solution.
As many, i done something myself as an exercise that you may use.
I designed a very small webapp with a few basic and probably reusable
features like gui for user/group managment and gui for
catalogues/messages managment, separation between sitemaps (general,
data, backoffice) and a styling pattern that uses extensively css to
separate design from logical structure. I think my solution for crud is
far from good, but maybe you'd be interesting in seeing the code and
maybe taking a few ideas ?
Marc
Jean-Christophe Kermagoret a écrit :
> Hello,
>
> For those who are interested, I uploaded a few documentation in the
> wiki about the E-CRUD Design Pattern.
>
> It is available from the Wiki Cocoon Frontpage in :
> * http://wiki.apache.org/cocoon/,
>
> or directly in :
> * http://wiki.apache.org/cocoon/DesignPattern/Overview
>
> There might be some interesting code and documentation (I hope :-)
>
> Your discussion is welcome, and, I will say more, awaited with great
> enthousiasm :-)
>
> It's a work in progress. If you have any question, or any remark or
> addition, don't hesitate to tell me, I will (or You may) correct it
> immediately.
>
> Jean-Christophe
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: E-CRUD Design Pattern
Posted by Thomas Lutz <ma...@gmx.at>.
Jean-Christophe Kermagoret wrote:
<some snips />
> I start from the principle that the template must reflect the
> structure (so the binding) of the data the user is editing (or
> searching).
<some snips />
This is ok for the basic CRUD stuff I think. The "framework" I am
working on now is not the first one, and one of the biggest problems I
had in previous tries was the step from "rapid prototyping" with basic
tables to very customized forms (better form layouts). To be continued
in a few lines...
> 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.
Well, I have to admit that there is not much reusing in the metadata
approach, at least regarding definition and binding. But, these two are
very tight coupled with the data layer. So let some "brute force" code
generators (with xlst or what so ever) do the work looked fine for me.
I am a bit afraid of specialities, too, but, from my experience
everything is rather simple as long as you stay with basic tables and do
not have too much business logic. Which usually applies to a rather big
(and annoying if handcoded) part of a web application (lookups, admin
tables,...), where you just have to take care of the layout.
At the moment my metadata stylesheets only take care of:
-datatypes
-primary keys
-structure (we work with some sort of tree objects)
-cardinality
-basic constraints
If there is a need for special layout, I just pass the generated
templates to the designer. Pretty selfdocumenting, as he sees all
template variables in the generated file, and just has to do some html
layout.
For everything that is more complicated I override the generated files
with humancoded stuff. To be continued in a few lines...
> Your description is very interesting, I think there will have a lot to
> learn from each other by sharing all this.
Oh yes :-) !
>
> How did you implement your solution ? Java, javaflow, xslt ?
-very custom and proprietary db layer
-Javaflow
-a lot of xslt that does the metadata to form files step
-some generators that gather data from the db layer (together with some
flow functions)
-jx templates to make it easier for the "designers"
-a lot of internal pipelines to decouple the components, very similar to
your sitemap pattern
Do avoid redundant code I have a extension of FormInstance.java, which
is the central form class in JavaFlow. Basically this extension handles
the error handling, as most of our validation is done by the db layer.
> There are a lot of things to do (GUI builder - to do, portlet
> integration - already done, inter portlet communication - already
> done, ...)
Yep, you're right. I am a Cocoon and Java newby, and the deeper I get
into it, the more I see the open tasks.
> 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 !!!
I think I'll have a look at bluexml.org this weekend :-) !
regards and a nice weekend :-),
tom
>
> 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
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: E-CRUD Design Pattern
Posted by Jean-Christophe Kermagoret <jc...@babelobjects.com>.
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
Re: E-CRUD Design Pattern
Posted by Thomas Lutz <ma...@gmx.at>.
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