Thanks all for your reply and sorry for the mess I did :) Marc Portier napisał(a):
> [executive summary] > - aggregate works both ways, it is about the form-model, not about > binding nor templating I though so at the begining, because it seams to be natural for me. I just encountered a problem and then looked at wiki and what I've found is "aggregatefield widget - used to edit the value of multiple fields through one textbox". I think that someone should change this because it leads to missunderstanding. > - 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 But this approach doesn't allow me to go back between forms. Or maybe I don't know something then please clarify that. > [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) Hmm. I cannot find that in 2.1.4. Currently I'm downloading nightly snapshot to check if it's availiable there. Thanks for pointing me. > 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 It is clear. As I mentioned above for me this approach is natural. I was missleaded by wiki. > [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. I completly agree. Multiform is a way of presentation not dependant on model. It is also true that validation is executed on model not on form. However the way of presentation shouldn't be limited by model. > 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. I cannot agree. Sometimes I need to allow user on first page to choose which page will be next. For example, on first page user can check some checkboxes and regarding to user choice I would like to show forms which are availiable for choosed by user options. I don't want him to waste a time for filling data which are not important for him. Moreover all data on availiable pages should be validated independently from others. So if user choice is page 1 and 3 then I would like to verify data availiable on page 1 and 3 and don't validate data specific for page 2. It was very nicely done in jXForms. I would like also to show confirm page and allow user to go back between pages. > 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) I also see great oportunity in introduction of widget-repositories. > 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) I agree that woody and flow are very good way for cocoon and we should follow it. Now modeling forms with UML is clear for me, because I can see real object and sequences. Hovewer I can't see any reason why we should give up multiforms. Kindly regards, Sebastian Gil --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
