You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Sebastian <cr...@klub.chip.pl> on 2004/04/18 21:24:00 UTC
Woody/Cocoon forms questions
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
--
Thought by thought we see our own mistakes.
mailto: create@klub.chip.pl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Woody/Cocoon forms questions
Posted by Joerg Heinicke <jo...@gmx.de>.
On 18.04.2004 21:24, 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'm not sure, but I think this is also matched by aggregatefield. There
is a aggregate sample and I think it works in both directions. Otherwise
why it is not possible to use 4 simple fields. You only need to concat
the 4 values in the binding then.
> 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.
Because both were not seen as a good enough base for further
development. Deprecation only means no further effort is put in them,
this is now put into Cocoon Forms. So IMO you can not attack our
decision to deprecate them, but only to remove them immediately.
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Woody/Cocoon forms questions
Posted by Leon Widdershoven <qa...@dds.nl>.
I don't know whether you use flowscript or xsp.
If you use flowscript, you could look at the custom validation demo.
That way you can
validate the data on the form using any logic (javascript) you wish.
If you use xsp you could use, before the map:act type=process an entry like
map:transform src="stylesheets/transform-NIP-node.xsl"/>
with in transform-NIP-node.xsl something like:
<xsl:match name="NIP-all">
<nip>
<xsl:value-of select="NIP-part1"/>-<xsl:value-of select="NIP-part2"/>
-<xsl::value-of select="NIP-part3"/>-<xsl:value-of select="NIP-prt4"/>
</nip>
</xsl:match>
and before the woody page is serialized you should split the nip field
of course in the four parts NIP-part1 to 4. That way woody thinks
there is a single field nip whereas the browser thinks there are
four fields.
Extremely hacky, but if you're using xsp there is afaik not really another
option as I did not see any indication that the default validation has
interrelationships.
I think in such a scenario I'd use javascript/flowscript to set a
validator function. That way you can totally separate the representation
of the data from the logic or underlying data as you have javascript
to transform the data into any format you'd wish.
This is not of much help, I realize. Sorry for that.
Leon
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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Woody/Cocoon forms questions
Posted by Sebastian <cr...@klub.chip.pl>.
Dnia Sun, 18 Apr 2004 21:47:03 +0200, Leon Widdershoven <qa...@dds.nl>
napisał:
> can't you put a Transformer with an appropriate xsl stylesheet (which
> combines the
> entries) just after the receiving match in the sitemap?
>
> Leon
Explain our your idea? What is the magic way to store walue in NIP property
of binded object? And how to execute validation? Anyway. I think it is
rather hacker approach than woody :)
Sebastian Gil
--
Thought by thought we see our own mistakes.
mailto: create@klub.chip.pl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Woody/Cocoon forms questions
Posted by Leon Widdershoven <qa...@dds.nl>.
can't you put a Transformer with an appropriate xsl stylesheet (which
combines the
entries) just after the receiving match in the sitemap?
Leon
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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Woody/Cocoon forms questions
Posted by Antonio Gallardo <ag...@agssa.net>.
Sebastian dijo:
> 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?
AFAIK, this is similar as 3 fields for a Date: day, month and year. The
CForms binding framework can do the work. Look for the binding samples.
You can manage the binding to allow it to load to 4 fields and on save to
get the 4 fields and store them in just one.
> 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.
If you are really aware, the dev maillist archive store the discusion +
the vote. :-D
Best Regards,
Antonio Gallardo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Woody/Cocoon forms questions
Posted by Sebastian <cr...@klub.chip.pl>.
> Since this error is on the aggregate-widget and that one is not actually
> on the template, there is no position where the (!) should be next to.
>
> Therefor you need to explitely position it with a separate
> <ft:validation-error />
>
> see also here:
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108176649831199&w=2
> and here:
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107486651220426&w=2
>
> and let's thank Vadim :-)
Hmm. Very hacky :) Anyway. I think there is another bug there :) I don't
know
if it's well known or if I should populate it on bugzilla.
Let me show my beautiful example :)
<fd:aggregatefield id="nip" required="false">
<fd:label>NIP:</fd:label>
<fd:datatype base="string">
<fd:validation>
<fd:nip>
<fd:failmessage>Invalid NIP number.</fd:failmessage>
</fd:nip>
</fd:validation>
</fd:datatype>
<fd:split pattern="([0-9]{3})-([0-9]{2,3})-([0-9]{2})-([0-9]{2,3})">
<fd:map group="1" field="part1"/>
<fd:map group="2" field="part2"/>
<fd:map group="3" field="part3"/>
<fd:map group="4" field="part4"/>
<fd:failmessage>Not a valid 10-digit NIP number.</fd:failmessage>
</fd:split>
<fd:combine expression='Concat(part1, "-", part2, "-", part3, "-",
part4)'/>
<fd:widgets>
<fd:field id="part1">
<fd:label>NIP:</fd:label>
<fd:datatype base="string"/>
</fd:field>
<fd:field id="part2">
<fd:label>-</fd:label>
<fd:datatype base="string"/>
</fd:field>
<fd:field id="part3">
<fd:label>-</fd:label>
<fd:datatype base="string"/>
</fd:field>
<fd:field id="part4">
<fd:label>-</fd:label>
<fd:datatype base="string"/>
</fd:field>
</fd:widgets>
</fd:aggregatefield>
"fd:split pattern" doesn't work correctly. For example. If I'll fill just
single
field then I get a message "Not a valid 10-digit NIP number.". That's
correct.
If I fill all fields with integers I get "Invalid NIP number.". That's
correct
and not correct :) In fact it is an invalid NIP, but I can provide value
1-1-1-1 which not match the pattern and I should get "Not a valid 10-digit
NIP
number.". Moreover if I will fill all fields but some of it will be a text
instead of number I will get an exception from my NIP validator :) because
of course it'll be validated against NIP rule not pattern. I've tried to
change data types for parts to integer but in this case it doesn't validate
at all and always returns "Not a valid 10-digit NIP number.".
Bug or not bug? And is it a well known bug? :)
Kindly regards,
--
Thought by thought we see our own mistakes.
mailto: create@klub.chip.pl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Woody/Cocoon forms questions
Posted by Marc Portier <mp...@outerthought.org>.
Sebastian wrote:
> Dnia Mon, 19 Apr 2004 22:41:50 +0200, Marc Portier
> <mp...@outerthought.org> napisał:
^^^^^^^ did I? gosh :-$
<snip />
>
> Ok. I've looked at C2.1.5. Lot of new stuff. It looks interesting.
> Saddly I'm not web developer anymore and don't have so much time
> to spend on it as I used to have. I just want to be align.
> Everything looks fine. I managed to get my beutiful NIP validator.
> And... I'm a little bit disapointed. Why? Because fail
> message on aggregatefield isn't working correctly. My model looks
> like:
>
<snip what="the elaborate sample snippet" />
>
> Now, when I try to enter incorrect NIP it is validated and form
> won't be submited. That's correct. Saddly information that
> NIP is incorrect is not presented by '!'. Well if I'll provide
> letter insted of digit I will get '!' for incorrect field but I don't
> have '!' for whole aggregation. So if digits are correct form
> won't be submited and user won't get feedback why it happens.
> Is it possible to make it visible or is it a bug in cforms?
>
Since this error is on the aggregate-widget and that one is not actually
on the template, there is no position where the (!) should be next to.
Therefor you need to explitely position it with a separate
<ft:validation-error />
see also here:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108176649831199&w=2
and here:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107486651220426&w=2
and let's thank Vadim :-)
>> I think it is, I do hope you now also understand the 'danger' in this
>> usage.
>
>
> Hmm. Okey I agree. I just have an idea. Of course it is not possible
> with current implementation but it could be the way for multiforms.
> Consider that we have additional value stored in continuation
> session which will hold information about current view. Then we can
> add information to form template about views. I mean additional info
> for widget on which page it should be visible. Now, depending on
> current value of our variable stored in session cforms block
> can validate/trigger getting submited values/do other stuff only for
> widgets availiable for current view. Succesfuly validated form
> allow cforms to change value of variable stored in session and
> change current view. Leaving current continuation point would be possible
> only when user will go through all forms. In sucha solution we
> have both advantages from multiforms and continuation. Main idea was
> taken from XForms. I like almost everything about cforms but I think
> there were some good ideas also in XForms.
>
I'm quite sure that is the case...
I have to say the above explanation is quite dense, and it fails at
making me see where this 'view' is different to the current 'form'
Isn't this really about just have a look at it differently, and mold
your thoughts around what cforms offers?
In any case, maybe you could elaborate with some snippets of flowscript
and form def files to hint at what you are implying...
regards,
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Woody/Cocoon forms questions
Posted by Sebastian <cr...@klub.chip.pl>.
Dnia Mon, 19 Apr 2004 22:41:50 +0200, Marc Portier <mp...@outerthought.org>
napisał:
> 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)
Ok. I've looked at C2.1.5. Lot of new stuff. It looks interesting.
Saddly I'm not web developer anymore and don't have so much time
to spend on it as I used to have. I just want to be align.
Everything looks fine. I managed to get my beutiful NIP validator.
And... I'm a little bit disapointed. Why? Because fail
message on aggregatefield isn't working correctly. My model looks
like:
<fd:aggregatefield id="nip" required="false">
<fd:label>NIP:</fd:label>
<fd:datatype base="string">
<fd:validation>
<fd:nip>
<fd:failmessage>Invalid NIP number.</fd:failmessage>
</fd:nip>
</fd:validation>
</fd:datatype>
<fd:split pattern="([0-9]{3})-([0-9]{2,3})-([0-9]{2})-([0-9]{2,3})">
<fd:map group="1" field="part1"/>
<fd:map group="2" field="part2"/>
<fd:map group="3" field="part3"/>
<fd:map group="4" field="part4"/>
<fd:failmessage>Not a valid 10-digit NIP number.</fd:failmessage>
</fd:split>
<fd:combine expression='Concat(part1, "-", part2, "-", part3,
"-",part4)'/>
<fd:widgets>
<fd:field id="part1">
<fd:label>NIP:</fd:label>
<fd:datatype base="integer"/>
</fd:field>
<fd:field id="part2">
<fd:label>-</fd:label>
<fd:datatype base="integer"/>
</fd:field>
<fd:field id="part3">
<fd:label>-</fd:label>
<fd:datatype base="integer"/>
</fd:field>
<fd:field id="part4">
<fd:label>-</fd:label>
<fd:datatype base="integer"/>
</fd:field>
</fd:widgets>
</fd:aggregatefield>
and template:
<fi:group>
<fi:styling layout="row"/>
<fi:items>
<ft:aggregate-widget id="nip">
<ft:widget id="part1"/>
<ft:widget id="part2"/>
<ft:widget id="part3"/>
<ft:widget id="part4"/>
</ft:aggregate-widget>
</fi:items>
</fi:group>
Now, when I try to enter incorrect NIP it is validated and form
won't be submited. That's correct. Saddly information that
NIP is incorrect is not presented by '!'. Well if I'll provide
letter insted of digit I will get '!' for incorrect field but I don't
have '!' for whole aggregation. So if digits are correct form
won't be submited and user won't get feedback why it happens.
Is it possible to make it visible or is it a bug in cforms?
> I think it is, I do hope you now also understand the 'danger' in this
> usage.
Hmm. Okey I agree. I just have an idea. Of course it is not possible
with current implementation but it could be the way for multiforms.
Consider that we have additional value stored in continuation
session which will hold information about current view. Then we can
add information to form template about views. I mean additional info
for widget on which page it should be visible. Now, depending on
current value of our variable stored in session cforms block
can validate/trigger getting submited values/do other stuff only for
widgets availiable for current view. Succesfuly validated form
allow cforms to change value of variable stored in session and
change current view. Leaving current continuation point would be possible
only when user will go through all forms. In sucha solution we
have both advantages from multiforms and continuation. Main idea was
taken from XForms. I like almost everything about cforms but I think
there were some good ideas also in XForms.
Kindly regards,
Sebastian Gil
--
Thought by thought we see our own mistakes.
mailto: create@klub.chip.pl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Woody/Cocoon forms questions
Posted by Marc Portier <mp...@outerthought.org>.
Sebastian wrote:
> Dnia Mon, 19 Apr 2004 15:18:38 +0200, Marc Portier
> <mp...@outerthought.org> 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/
mpo@outerthought.org mpo@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Woody/Cocoon forms questions
Posted by Sebastian <cr...@klub.chip.pl>.
Dnia Mon, 19 Apr 2004 15:18:38 +0200, Marc Portier <mp...@outerthought.org>
napisał:
> thx for spotting, since it is a wiki you should be encouraged to just fix
I did so.
>>> - 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.
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.
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)?
> 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.
>> 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.
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.
Kindly regards,
Sebastian Gil
--
Thought by thought we see our own mistakes.
mailto: create@klub.chip.pl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Woody/Cocoon forms questions
Posted by Marc Portier <mp...@outerthought.org>.
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/
mpo@outerthought.org mpo@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Woody/Cocoon forms questions
Posted by Leon Widdershoven <qa...@dds.nl>.
> 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.
I really think javascript/flowscript is invented for just this
type of action. Woody, JXTemplates and flowscript together (optionally
bookmarking the state) allows all kinds of validation, as long as it
can be expressed in javascript or java (which is almost everything).
The form is there literally the GUI with which the application interacts
with the user. I think you can't really be more flexible than that.
Leon
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Woody/Cocoon forms questions
Posted by Sebastian <cr...@klub.chip.pl>.
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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Woody/Cocoon forms questions
Posted by Marc Portier <mp...@outerthought.org>.
Sebastian,
[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/
mpo@outerthought.org mpo@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org