[executive summary]
- aggregate works both ways, it is about the form-model, not about binding nor templating
- multiform is in my head about controlling the flow between forms. As such the correct separation is: let cforms describe one form, let flow control the decission to go from one to the other
[aggregate]
the wd:aggregate allows you to centrally describe your form-data-model with the validation you have in place.
the decission to visualize and/or bind those values as 'one aggregated value' or 'multiple split values' is easy in your template (see either example binding/03aggregate or the date-aggregate sample)
equally separated from the model is the decission to bind the value to the backend in one <fb:value> on the level of the aggregate or in multiple fb:value on the level of the separate fields
as such 'aggregate' means that the model IS aggregating different split parts. I hope you see why we don't need a de-aggregate widget (which was suggested in the past) in the model you have the detail available in the binding and/or template you choose at which level (combined or split) you step in
[multiform]
the multiform issue is AFAICS out of the scope of the form-model which is there to describe ONE form, and to manage the lifecycle (validation and eventhandling) of that one thing.
That by itself is hard enough as it is. Not (currently) adding to the complexity the unpredictable various ways of splitting one form over various interactions actually follows up on the fact that modelling your form is (also) about describing the valid URI-request-params to your form interaction.
In fact you should look at cforms as a convenient way to describe/model the form as a single interaction-interface (i.e. the URI-request-params) that offers you the extra of useful data-typing, validation rules and some (local) event-handling.
In a web-context I truly see this formal interface declaration building up something I would call a unit-of-interaction to be something truly valuable. IMHO adding multi-form support here seems to be blurring that nice responsibility.
From that angle I think the (current) work on introducing widget-repositories will largely simplify building up various forms (interaction-units) based on the same set of predefined widgets (see http://wiki.cocoondev.org/Wiki.jsp?page=WoodyScratchpad)
What remains then is building up one application by glueing these interaction-points together. I think most of us are just doing that by means of flowscript and the fact that there hasn't emerged some more abstract format to hook those up as e.g. wizards kinda tells me that flowscript by itself is a perfect match for the flexibility you need anyway. (that is my feeling)
HTH, -marc=
Sebastian wrote:
Hi there,
I've following problem. I'm using woody with binding to hibernate.
In my database I've field called NIP (it is polish rate payer
identification number). It has 4 parts separated by '-'. I've written
successfuly validation class for this number and everything works
fine. Now I would like to change the way user can modify this number.
I would like to show 4 edits instead of one and then add '-' between
them, validate NIP and then store it in database. It is exaclty opposite
to wd:aggregatefield which allows to merge several fields into single
edit. My first idea was to create 4 wd:field's but what then? How to
merge them to allow validation on whole string and what is more important
how to merge them to allow binding just to single property?
Any idea? I hope that it is not another unimplemented feature like multipage
forms. It will always remains a great mystery for me why XForms and JXForms
were deprecated when Woody is not mature enough to be the only form handler
for Cocoon.
Thanks in advance, Sebastian Gil
-- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
