You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Stefan Burkard <sb...@previon.ch> on 2004/02/18 00:08:40 UTC
woody-forms and templates - bug or feature?
hi cocoon-users
i was very glad to read in the woody-wiki that xml-based
form-definitions and templates that "call" the form-widgets are
separated, so that many templates can use one single form-definition.
but now, i ran into a problem and i don't know if it's a bug or a
feature :-)
i have a contact-form on my website, but to provide the visitor just the
form-fields he need, i let him first choose what subject his contact is
about. if he wanna report me any problems with the page, he gets other
form-fields than when he wanna send me a link for my link-list.
so, i wrote a single contact-form-definition with all possible widgets.
these include
- name
- e-mail
- message
- link
- description
and others
while "name" and "e-mail" are widgets that every form-template uses,
some of the widgets are only used by one single form-template. for
example just the the form to send me new links shows the link-field.
and now the problem: because it makes no sense, when the form to send
new links can be submited without a link, i set the link-widget
required="true". BUT, if any other template don't display the link-field
at all, it can never be submited because the link-field is not true
(what a wonder when it's not in the form at all :-)).
is this a bug or a feature? do i really need to write a form-definition
for every "type" of my contact-form?
for the moment it's no problem to set all required-attributes of the
widgets to "false", but it's not a smart solution at all...
thanks for your input and greetings
stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: woody-forms and templates - bug or feature?
Posted by Tim Larson <ti...@keow.org>.
On Tue, Feb 17, 2004 at 06:36:54PM -0600, Carlos Ch?vez wrote:
> Hi stefan.
>
> See http://wiki.cocoondev.org/Wiki.jsp?page=TimLarson
>
> I think the "union" help you.
The "union" widget is present in Cocoon 2.1.4 as a first try at
supporting optional widgets, bindings, and templates.
This functionality is being redesigned as a new "choice" widget.
You can see the preliminary design at:
http://wiki.cocoondev.org/Wiki.jsp?page=WoodyScratchpad
This is a great time to comment on the proposed design to make
sure the end result will fill your needs.
Feel free to add comments on the wiki page or on the email lists,
whichever is more comfortable/convenient. If necessary, I can
also discuss this on the #cocoon irc channel, just email me
first so I will know when to be watching the channel.
--Tim Larson
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: woody-forms and templates - bug or feature?
Posted by Carlos Chávez <cc...@agsoftware.dnsalias.com>.
Stefan Burkard Escribio :-)
> hi cocoon-users
>
> i was very glad to read in the woody-wiki that xml-based
> form-definitions and templates that "call" the form-widgets are
> separated, so that many templates can use one single form-definition.
> but now, i ran into a problem and i don't know if it's a bug or a
> feature :-)
>
> i have a contact-form on my website, but to provide the visitor just the
> form-fields he need, i let him first choose what subject his contact is
> about. if he wanna report me any problems with the page, he gets other
> form-fields than when he wanna send me a link for my link-list.
>
> so, i wrote a single contact-form-definition with all possible widgets.
> these include
> - name
> - e-mail
> - message
> - link
> - description
> and others
>
> while "name" and "e-mail" are widgets that every form-template uses,
> some of the widgets are only used by one single form-template. for
> example just the the form to send me new links shows the link-field.
>
> and now the problem: because it makes no sense, when the form to send
> new links can be submited without a link, i set the link-widget
> required="true". BUT, if any other template don't display the link-field
> at all, it can never be submited because the link-field is not true
> (what a wonder when it's not in the form at all :-)).
>
> is this a bug or a feature? do i really need to write a form-definition
> for every "type" of my contact-form?
>
> for the moment it's no problem to set all required-attributes of the
> widgets to "false", but it's not a smart solution at all...
>
> thanks for your input and greetings
> stefan
Hi stefan.
See http://wiki.cocoondev.org/Wiki.jsp?page=TimLarson
I think the "union" help you.
Cheers,
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
--
Carlos Chávez
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: woody-forms and templates - bug or feature?
Posted by Joerg Heinicke <jo...@gmx.de>.
That's a known feature. There were already discussions on the dev list
on this "optionally required" feature [1].
For the moment it's not really supported, but you have different
possibilities: either a xreporter expression as suggested by Vadim [2]
or doing the same with the new JavaScript validation feature [3] similar
to the sample [4] (with widget.getForm().getWidget('id') you can access
the _other widget_ containing the status of the selection and make _this
widget_ optionally required).
For the fact that the form is just redisplayed and somebody can not
track it down why there exists a bug in bugzilla [5].
Joerg
[1] http://marc.theaimsgroup.com/?t=107349479500003&r=1&w=4
[2] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107352171910636&w=4
[3] http://marc.theaimsgroup.com/?t=107591706500003&r=1&w=4
[4]
http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/woody/samples/forms/form1.xml?annotate=1.20#220
[5] http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24180
On 18.02.2004 00:08, Stefan Burkard wrote:
> hi cocoon-users
>
> i was very glad to read in the woody-wiki that xml-based
> form-definitions and templates that "call" the form-widgets are
> separated, so that many templates can use one single form-definition.
> but now, i ran into a problem and i don't know if it's a bug or a
> feature :-)
>
> i have a contact-form on my website, but to provide the visitor just the
> form-fields he need, i let him first choose what subject his contact is
> about. if he wanna report me any problems with the page, he gets other
> form-fields than when he wanna send me a link for my link-list.
>
> so, i wrote a single contact-form-definition with all possible widgets.
> these include
> - name
> - e-mail
> - message
> - link
> - description
> and others
>
> while "name" and "e-mail" are widgets that every form-template uses,
> some of the widgets are only used by one single form-template. for
> example just the the form to send me new links shows the link-field.
>
> and now the problem: because it makes no sense, when the form to send
> new links can be submited without a link, i set the link-widget
> required="true". BUT, if any other template don't display the link-field
> at all, it can never be submited because the link-field is not true
> (what a wonder when it's not in the form at all :-)).
>
> is this a bug or a feature? do i really need to write a form-definition
> for every "type" of my contact-form?
>
> for the moment it's no problem to set all required-attributes of the
> widgets to "false", but it's not a smart solution at all...
>
> thanks for your input and greetings
> stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org