Sebastian wrote:
Dnia Mon, 19 Apr 2004 15:18:38 +0200, Marc Portier <[EMAIL PROTECTED]> napisał:
thx for spotting, since it is a wiki you should be encouraged to just fix
I did so.
thx.
- 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!!!
For sure. I know that. And I didn't stop on sample-form2 :) I still don't understand how do you know if user pushed next or prev button on my form. Flow below doesn't handle that.
make next and prev buttons on your form of type fd:submit after the showForm you can check the submit-id on the form
see the aggregate-sample with the 'switch' button
(of course that is a somewhat giving you the idea that you _should_ have multiple templates for one form, but you should at least notice that both templates mention ALL the widgets from the form-definition file)
Sorry :) I can't get the idea. Continuation throws me to the place where I was and that's okey with me and what next? As I mentioned before I want to go back in flow or go forward as usualy. It's not a problem for me to do showform1; showform2; etc. I would like to know how determine which button was pressed and depending on it go forward or backward. And if possible do it as much generic as it is possible. For example to set number of forms by parameter in flow. I did sucha generic action for XForms and I can't see the same idea in flow. My problem is that I need someone to put some light on me :)
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! }
[...]
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's true, but I can show different templates using selected widgets.
hm, but with sometimes unwanted effects, no?
e.g. a missing boolean-widget will automatically be set to false
this is a consequence of how these booleans (radio buttons) are (not)transmitted from HTML forms
would need to do a full scan on the widgets to see how others would react (don't e.g. required widgets get their validation error fired?)
So for eg. I have widgets: name, surname, age, sex and then I can use template transformer with template1 containing name and surname and then template2 containing age and sex. Do you agree with me that I can do that on separated pages and still have the same data model (single)?
yes, it might (will often) work, but rather unintentionally so.
like you say yourself: it is more then one form... but it is one application, and it should be glued together by the flow
For sure, but as I mentioned above it could be glued also with a single model. Well, that's how I see it.
I understand, but it's not how things are intended to work as explained above.
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?
No. Idea described above. So different pages but still the same model.
got that, but there is little preventing you to make it different forms, right? (as soon as you get the flow thingy in shape)
Maybe I'm fucking something here :) but I don't see any problems in handling forms in this way. I just need that super sexy flow which allow me to go back and forward on number templates.
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?
exactly
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
I want to handle them on flow level but with using different templates for the same model. Excuse me, I think we missunderstood each other and this is my fault because I didn't provide to you my completly vision of the system. I hope now it is clear.
I think it is, I do hope you now also understand the 'danger' in this usage.
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]
