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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
