Sebastian wrote:
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.
thx for spotting, since it is a wiki you should be encouraged to just fix
- 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.
why do you think that is the case?
you can easily have one flow-script function to be handling more then one form!!!
of course everyone stops at using the sample-form2 implied construct:
<map:call function="handleForm"> <map:parameter name="function" value="form2xml"/> <map:parameter name="form-definition" value="forms/form2_model.xml"/> <map:parameter name="bindingURI" value="forms/form2_bind_xml.xml"/> </map:call>
where you just have 2 create your own form2xml() function that receives a ready made form!
but please understand that this is done by handleForm() and that it is only a very convenient thingy applicable (only) in the most simple case.
Pls understand that the above is just a shorthand for this:
<map:call function="test2" />
where you now have your own function that creates forms:
function test2() {
var form = new Form("form2xml");
form.createBinding("forms/form2_bind_xml.xml"); // after above initialization of this one form
// you can load/save the data from/to backend models
// and you can manage the form in any way you already know
form.showForm("form2pipe");// or replace it by another form = previousForm;
// or manage an array
myForms[2] = new Form("theThirdFormdefinition");// be creative, go wild! }
Maybe now you see how you can easily handle more then form from your flow? The flexibility here is a lot higher then the one we could possibly provide through declarative XML definition files, no?
[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.
you are right, aggregate doesn't do this until recently (hence the doco mismatch too)
see: it might be 'natural' to you, but it wasn't to us from the start :-)
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.
feel free to fix
[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.
I think my point is that the form-model is not about the presentation, it is about the HTTP protocol, and which parameters are available/expected in the communication.
And, yes it does limit: the presentation can only show widgets which were definied in the first place. How else?
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
like you say yourself: it is more then one form... but it is one application, and it should be glued together by the flow
waste a time for filling data which are not important for him. Moreover all data on availiable pages should be validated independently from others.
surely different forms, no?
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.
not even show page 2 would be my guess?
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.
I didn't say we should give up on multiforms/wizards: they just shouldn't be handled at the level of cforms IMHO
regards, -marc= -- 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]
