You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by oceatoon <t....@systheo.com> on 2004/06/27 15:21:16 UTC
Show/Hide Widgets
Hi everyone
I would like to be able to show/hide widgets according to certain events
(Ex: in the Car Selector sample in the Forms block, I would like to show
the car type widget only once the make has been choosen).
Does anybody know how this is possible, do I have to change template files
removing the concerned widget or is there a show/hide attribute???
Thanks for your thoughts.
Tibor
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Show/Hide Widgets
Posted by Tim Larson <ti...@keow.org>.
On Mon, Jul 05, 2004 at 07:49:51PM +0100, Tim Larson wrote:
> On Mon, Jul 05, 2004 at 01:44:26PM +0200, Joerg Heinicke wrote:
> > On 05.07.2004 12:35, Vilya Harvey wrote:
> > >If we had fd:case, wouldn't that imply that we'd have to duplicate
> > >widget declarations when the same widget appears in more than one case?
> >
> > Yes, that would imply it, but it is not different than before: the cases
> > are mutually exclusive. To reuse widget declarations there are still
> > fd:class and fd:new.
>
> Note that these only reuse the widget *definitions*, not the widget
> instances, so would save typing but not cause cases to share values.
> Union cases really are mutually exclusive. This is one of the things we
> are trying to fix in the choice/case and now the masks proposals.
Btw, you could wrap each individual widget in its own union widget, and
have groups of unions share the same caseWidgets. This way you can
*simulate* having cases share some widgets. Of course this is clumsy
(and a motivation for coming up with something better), but at least it
is a solution that works for now.
--Tim Larson
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Show/Hide Widgets
Posted by Tim Larson <ti...@keow.org>.
On Mon, Jul 05, 2004 at 01:44:26PM +0200, Joerg Heinicke wrote:
> On 05.07.2004 12:35, Vilya Harvey wrote:
> >If we had fd:case, wouldn't that imply that we'd have to duplicate
> >widget declarations when the same widget appears in more than one case?
>
> Yes, that would imply it, but it is not different than before: the cases
> are mutually exclusive. To reuse widget declarations there are still
> fd:class and fd:new.
Note that these only reuse the widget *definitions*, not the widget
instances, so would save typing but not cause cases to share values.
Union cases really are mutually exclusive. This is one of the things we
are trying to fix in the choice/case and now the masks proposals.
> >BTW I also have an extension of the repeater widget which handles
> >pagination, that I'd like to submit.
>
> Looking forward, it would definitely be an interesting contribution.
Yes, I would like to see that too.
--Tim Larson
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Show/Hide Widgets
Posted by Joerg Heinicke <jo...@gmx.de>.
On 05.07.2004 12:35, Vilya Harvey wrote:
>> The solution (hoping that Tim also reads it):
>> The implicite cases are really hard to understand, especially as there is
>> fb:case and ft:case, but no fd:case. The fd:struct I use also has
>> effect on the
>> template and binding (I have to add them there too to get the same
>> tree) and
>> complicates them unnecessarily. Why don't we simply introduce
>> explicite fd:case
>> - until we have masks ;-)
>>
>> WDYT?
>
> If we had fd:case, wouldn't that imply that we'd have to duplicate
> widget declarations when the same widget appears in more than one case?
Yes, that would imply it, but it is not different than before: the cases
are mutually exclusive. To reuse widget declarations there are still
fd:class and fd:new.
> Sure thing, I'm happy to contribute it. I don't quite have the editing
> part working yet, but will submit it as soon as I do. How do I go about
> submitting it?
http://cocoon.apache.org/community/contrib.html
http://cocoon.apache.org/2.1/howto/howto-patch.html
http://cocoon.apache.org/2.1/howto/howto-bugzilla.html
> BTW I also have an extension of the repeater widget which handles
> pagination, that I'd like to submit.
Looking forward, it would definitely be an interesting contribution.
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Show/Hide Widgets
Posted by Philippe Guillard <pg...@soociety.com>.
Hi,
I'm looking also for a simple example of union/struct other than
form_gui, as it is not so easy to understand, i followed this thread
(with that name) catched in July. Would be please to take a look at that
sample!
Thanks,
Phil
On Mon, 2004-07-05 at 18:35, Vilya Harvey wrote:
> Joerg Heinicke wrote:
> > The good news: It is not an error in the implementation, but in your form
> > definition. But it's still a "not so intuitive" implementation then.
>
> Thanks so much for this! With your alterations it works like a charm.
>
> > The solution (hoping that Tim also reads it):
> > The implicite cases are really hard to understand, especially as there is
> > fb:case and ft:case, but no fd:case. The fd:struct I use also has effect on the
> > template and binding (I have to add them there too to get the same tree) and
> > complicates them unnecessarily. Why don't we simply introduce explicite fd:case
> > - until we have masks ;-)
> >
> > WDYT?
>
> If we had fd:case, wouldn't that imply that we'd have to duplicate widget
> declarations when the same widget appears in more than one case?
>
> > To Vilya: That's a very nice sample of using union. As I was searching for a
> > simpler sample than the Form Model GUI do you want to provide it to the project?
> > Maybe with the "real" functionality of editing a row as for the moment one can
> > only cancel the editing. Would be really cool - and I have less work to do ;-)
>
> Sure thing, I'm happy to contribute it. I don't quite have the editing part
> working yet, but will submit it as soon as I do. How do I go about
> submitting it?
>
> BTW I also have an extension of the repeater widget which handles
> pagination, that I'd like to submit.
>
> Cheers,
> Vil.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Show/Hide Widgets
Posted by Vilya Harvey <vi...@lineone.net>.
Joerg Heinicke wrote:
> The good news: It is not an error in the implementation, but in your form
> definition. But it's still a "not so intuitive" implementation then.
Thanks so much for this! With your alterations it works like a charm.
> The solution (hoping that Tim also reads it):
> The implicite cases are really hard to understand, especially as there is
> fb:case and ft:case, but no fd:case. The fd:struct I use also has effect on the
> template and binding (I have to add them there too to get the same tree) and
> complicates them unnecessarily. Why don't we simply introduce explicite fd:case
> - until we have masks ;-)
>
> WDYT?
If we had fd:case, wouldn't that imply that we'd have to duplicate widget
declarations when the same widget appears in more than one case?
> To Vilya: That's a very nice sample of using union. As I was searching for a
> simpler sample than the Form Model GUI do you want to provide it to the project?
> Maybe with the "real" functionality of editing a row as for the moment one can
> only cancel the editing. Would be really cool - and I have less work to do ;-)
Sure thing, I'm happy to contribute it. I don't quite have the editing part
working yet, but will submit it as soon as I do. How do I go about
submitting it?
BTW I also have an extension of the repeater widget which handles
pagination, that I'd like to submit.
Cheers,
Vil.
--
__
o| _. / \|o._ _ _ ._ _ ._ _ _|_
\/ ||\/(_|| (|/||| |(/_(_)| |(/_o| |(/_ |_
/ \__
http://website.lineone.net/~vilya
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Show/Hide Widgets
Posted by Joerg Heinicke <jo...@gmx.de>.
On 05.07.2004 21:12, Tim Larson wrote:
>>>I agree that leaving out fd:case was a mistake, but I am not sure how to
>>>make it better without breaking existing forms. If we add and require
>>>fd:case it would be clearer and help avoid errors and misunderstandings,
>>>but it would break any forms that are already using "union" widgets.
>>>
>>>It would be easy to add a fd:case, just copy or extend the "struct"
>>>widget, because they both act the same, or at least pretty close.
>>
>>Why do you need to force the people to use fd:case? Just adding fd:case
>>should not break anything. It should behave the same way as with my
>>problem of missing fb:case last week.
>
>
> We would not have to force its use, but if it were required it would
> help make some programming errors easier to spot and fix. But, I guess
> just adding and documenting fd:case, without actually requiring it would
> be best for now. We can add it to the examples and change the docs to
> only show union with case's and not show the single widget or struct
> "hacks".
+1 But I want to/must reduce my time for Cocoon for the next months, so
I won't attack it.
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Show/Hide Widgets
Posted by Tim Larson <ti...@keow.org>.
On Mon, Jul 05, 2004 at 08:17:01PM +0200, Joerg Heinicke wrote:
> On 05.07.2004 20:46, Tim Larson wrote:
> >I agree that leaving out fd:case was a mistake, but I am not sure how to
> >make it better without breaking existing forms. If we add and require
> >fd:case it would be clearer and help avoid errors and misunderstandings,
> >but it would break any forms that are already using "union" widgets.
> >
> >It would be easy to add a fd:case, just copy or extend the "struct"
> >widget, because they both act the same, or at least pretty close.
>
> Why do you need to force the people to use fd:case? Just adding fd:case
> should not break anything. It should behave the same way as with my
> problem of missing fb:case last week.
We would not have to force its use, but if it were required it would
help make some programming errors easier to spot and fix. But, I guess
just adding and documenting fd:case, without actually requiring it would
be best for now. We can add it to the examples and change the docs to
only show union with case's and not show the single widget or struct
"hacks".
--Tim Larson
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Show/Hide Widgets
Posted by Joerg Heinicke <jo...@gmx.de>.
On 05.07.2004 20:46, Tim Larson wrote:
>>The solution (hoping that Tim also reads it):
>>The implicite cases are really hard to understand, especially as there is
>>fb:case and ft:case, but no fd:case. The fd:struct I use also has effect on the
>>template and binding (I have to add them there too to get the same tree) and
>>complicates them unnecessarily. Why don't we simply introduce explicite fd:case
>>- until we have masks ;-)
>
>
> I agree that leaving out fd:case was a mistake, but I am not sure how to
> make it better without breaking existing forms. If we add and require
> fd:case it would be clearer and help avoid errors and misunderstandings,
> but it would break any forms that are already using "union" widgets.
>
> It would be easy to add a fd:case, just copy or extend the "struct"
> widget, because they both act the same, or at least pretty close.
Why do you need to force the people to use fd:case? Just adding fd:case
should not break anything. It should behave the same way as with my
problem of missing fb:case last week.
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Show/Hide Widgets
Posted by Tim Larson <ti...@keow.org>.
On Fri, Jul 02, 2004 at 10:40:59PM +0000, Joerg Heinicke wrote:
> The solution (hoping that Tim also reads it):
> The implicite cases are really hard to understand, especially as there is
> fb:case and ft:case, but no fd:case. The fd:struct I use also has effect on the
> template and binding (I have to add them there too to get the same tree) and
> complicates them unnecessarily. Why don't we simply introduce explicite fd:case
> - until we have masks ;-)
I agree that leaving out fd:case was a mistake, but I am not sure how to
make it better without breaking existing forms. If we add and require
fd:case it would be clearer and help avoid errors and misunderstandings,
but it would break any forms that are already using "union" widgets.
It would be easy to add a fd:case, just copy or extend the "struct"
widget, because they both act the same, or at least pretty close.
--Tim Larson
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Show/Hide Widgets
Posted by Joerg Heinicke <jo...@gmx.de>.
Vilya Harvey <vilya <at> lineone.net> writes:
> > This means validation is caused by them though it should not?
> > http://cocoon.apache.org/2.1/userdocs/forms/widget_submit.html
>
> Yes. It also means that execution is resumed in the flowscript that sent the
> page, if the validation passes.
>
> I've created a simple example which demonstrates the problem. I can't attach
> it as the mailing list doesn't accept zip files, but if you have the time
> and are willing to look at it then drop me a line and I'll email it to you
> directly. I'd really appreciate that.
A perfect testcase to simplify developer's life: unzip, copy, start Cocoon,
request - I love that. Thanks.
The good news: It is not an error in the implementation, but in your form
definition. But it's still a "not so intuitive" implementation then.
The reason: A request is processed by traversing through the tree and processing
all widgets (readFromRequest() and validate() and so on). The effect you saw was
caused by not processing the cancel widget at all, so the submitWidget of the
form was not set correctly and the form assumed you hitted submit.
The errors: Two errors have been in your form definition.
The first one is hinted on at http://wiki.apache.org/cocoon/TimLarson
#head-72d1bc1786787b9f5cf6f8701a1fb442f4f59285-2 :
"A container widget (Repeater, Struct, Union, or sort-of AggregateField) must be
used for union cases that need to hold multiple widgets." While the union
binding and the union in the template have an explicit case, the form definition
has not (but obviously an implicit one) and you have to use a container widget
for it. Additionally the container widget must have the id of the caseWidget's
value, here 'editingInt'. Union processing continues only for its children named
like the caseWidget's value.
The second error was fd:field for your case/control widget 'editIntControl'. So
the value will always be read from request and as you did not provide an input
field for example, it will always be null. Changed it to fd:output, so it won't
be read from request, and it works now.
The solution (hoping that Tim also reads it):
The implicite cases are really hard to understand, especially as there is
fb:case and ft:case, but no fd:case. The fd:struct I use also has effect on the
template and binding (I have to add them there too to get the same tree) and
complicates them unnecessarily. Why don't we simply introduce explicite fd:case
- until we have masks ;-)
WDYT?
To Vilya: That's a very nice sample of using union. As I was searching for a
simpler sample than the Form Model GUI do you want to provide it to the project?
Maybe with the "real" functionality of editing a row as for the moment one can
only cancel the editing. Would be really cool - and I have less work to do ;-)
Thanks,
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Show/Hide Widgets
Posted by Vilya Harvey <vi...@lineone.net>.
Joerg Heinicke wrote:
> On 30.06.2004 12:05, Vilya Harvey wrote:
>> Sorry, I wasn't being clear. What I was trying to say is that action
>> widgets which occur inside a union seem to behave as if they were
>> submit widgets, whereas action widgets outside of a union behave as
>> expected. Hopefully that makes a bit more sense...
>
>
> This means validation is caused by them though it should not?
> http://cocoon.apache.org/2.1/userdocs/forms/widget_submit.html
Yes. It also means that execution is resumed in the flowscript that sent the
page, if the validation passes.
I've created a simple example which demonstrates the problem. I can't attach
it as the mailing list doesn't accept zip files, but if you have the time
and are willing to look at it then drop me a line and I'll email it to you
directly. I'd really appreciate that.
Cheers,
Vil.
--
__
o| _. / \|o._ _ _ ._ _ ._ _ _|_
\/ ||\/(_|| (|/||| |(/_(_)| |(/_o| |(/_ |_
/ \__
http://website.lineone.net/~vilya
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Show/Hide Widgets
Posted by oceatoon <t....@systheo.com>.
That's true Which brings me back to the template xslt solution (for my part
I don't need the validation so I don't have the problem). Another way
might be tosimply use css rules on my hidable widgets
display = none, and swap the rule on changes.
Tibor
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Show/Hide Widgets
Posted by Joerg Heinicke <jo...@gmx.de>.
On 01.07.2004 11:13, oceatoon wrote:
> Just a thought,
>
> would it be difficult and wouldn't it be interesting to implement a
> visible="true/false" attribute on the widgets definition (just like the
> required="true/false") ?
That's not an issue of the form definition, but the form styling, so it
is done in the template.
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Show/Hide Widgets
Posted by oceatoon <t....@systheo.com>.
Just a thought,
would it be difficult and wouldn't it be interesting to implement a
visible="true/false" attribute on the widgets definition (just like the
required="true/false") ?
Tibor
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Show/Hide Widgets
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On 1 Jul 2004, at 23:16, Joerg Heinicke wrote:
> On 01.07.2004 10:37, oceatoon wrote:
>
>> Hello everyone Thanks for the answers, and the paths to solutions
>> I went through Tim Larson's explanation, and GUI model that really
>> give
>> great ground for dynamic implementation, but also come with a certain
>> complexity that I beleive would take me more time to overcome, and I
>> don't
>> necessarely need so much freedom in the definition since my
>> definition file
>> is fixed (I have a fixed number of widgets). But it gave me the idea
>> to simply generate my CForms with complete
>> Definition file, and then do the selection of what I want or don't
>> want to
>> show by XSLT processing the template file.
>> if anybody knows if this will be problematic, Warn me before the
>> useless
>> work is done ;) Thanks for the thoughts.
>
> It *can* cause problems, e.g. when you hide widgets that have
> validation errors or are required, so union widget would be the better
> solution. But you are right, the GUI model sample is to complex. Maybe
> I have enough spare time tomorrow.
I for one, can make neither head nor tail of the union|struct|new|class
widgets.
I think they'd allow me to make a more powerful form for the Query Bean
stuff, so I'd love to see some simpler examples if you get the time.
regards Jeremy
--------------------------------------------------------
If email from this address is not signed
IT IS NOT FROM ME
Always check the label, folks !!!!!
--------------------------------------------------------
Re: Show/Hide Widgets
Posted by Joerg Heinicke <jo...@gmx.de>.
On 01.07.2004 10:37, oceatoon wrote:
> Hello everyone
> Thanks for the answers, and the paths to solutions
>
> I went through Tim Larson's explanation, and GUI model that really give
> great ground for dynamic implementation, but also come with a certain
> complexity that I beleive would take me more time to overcome, and I don't
> necessarely need so much freedom in the definition since my definition file
> is fixed (I have a fixed number of widgets).
> But it gave me the idea to simply generate my CForms with complete
> Definition file, and then do the selection of what I want or don't want to
> show by XSLT processing the template file.
>
> if anybody knows if this will be problematic, Warn me before the useless
> work is done ;)
> Thanks for the thoughts.
It *can* cause problems, e.g. when you hide widgets that have validation
errors or are required, so union widget would be the better solution.
But you are right, the GUI model sample is to complex. Maybe I have
enough spare time tomorrow.
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Show/Hide Widgets
Posted by oceatoon <t....@systheo.com>.
Hello everyone
Thanks for the answers, and the paths to solutions
I went through Tim Larson's explanation, and GUI model that really give
great ground for dynamic implementation, but also come with a certain
complexity that I beleive would take me more time to overcome, and I don't
necessarely need so much freedom in the definition since my definition file
is fixed (I have a fixed number of widgets).
But it gave me the idea to simply generate my CForms with complete
Definition file, and then do the selection of what I want or don't want to
show by XSLT processing the template file.
if anybody knows if this will be problematic, Warn me before the useless
work is done ;)
Thanks for the thoughts.
Tibor
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Show/Hide Widgets
Posted by Joerg Heinicke <jo...@gmx.de>.
On 30.06.2004 12:05, Vilya Harvey wrote:
>>> Have you (or anyone else) noticed a bug with action widgets inside a
>>> union? The behaviour I'm seeing is that they always cause the form to
>>> be submitted, rather than just updated. It's annoying because I'm
>>> trying to create a popup detail area which contains a button to hide
>>> itself, but instead of hiding the detail area the button submits the
>>> entire form. Am I just doing something dumb, or is this a bug in CForms?
>>
>> Is an action widget not always a submit button by default? Only the
>> behaviour on server side is different. I guess the above is unrelated
>> to union. You would have to customize the forms stylesheets for your
>> special type of action. I did it myself with an fi:styling/@type='link'.
>
> Sorry, I wasn't being clear. What I was trying to say is that action
> widgets which occur inside a union seem to behave as if they were submit
> widgets, whereas action widgets outside of a union behave as expected.
> Hopefully that makes a bit more sense...
This means validation is caused by them though it should not?
http://cocoon.apache.org/2.1/userdocs/forms/widget_submit.html
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Show/Hide Widgets
Posted by Vilya Harvey <vi...@lineone.net>.
Joerg Heinicke wrote:
> On 30.06.2004 11:00, Vilya Harvey wrote:
>> Have you (or anyone else) noticed a bug with action widgets inside a
>> union? The behaviour I'm seeing is that they always cause the form to
>> be submitted, rather than just updated. It's annoying because I'm
>> trying to create a popup detail area which contains a button to hide
>> itself, but instead of hiding the detail area the button submits the
>> entire form. Am I just doing something dumb, or is this a bug in CForms?
>
>
> Is an action widget not always a submit button by default? Only the
> behaviour on server side is different. I guess the above is unrelated to
> union. You would have to customize the forms stylesheets for your
> special type of action. I did it myself with an fi:styling/@type='link'.
Sorry, I wasn't being clear. What I was trying to say is that action widgets
which occur inside a union seem to behave as if they were submit widgets,
whereas action widgets outside of a union behave as expected. Hopefully that
makes a bit more sense...
Cheers,
Vil.
--
__
o| _. / \|o._ _ _ ._ _ ._ _ _|_
\/ ||\/(_|| (|/||| |(/_(_)| |(/_o| |(/_ |_
/ \__
http://website.lineone.net/~vilya
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Show/Hide Widgets
Posted by Joerg Heinicke <jo...@gmx.de>.
On 30.06.2004 11:00, Vilya Harvey wrote:
>> This is possible using the union widget. I did it myself on Friday.
>> The resources I used were
>> http://wiki.cocoondev.org/Wiki.jsp?page=TimLarson and the form model
>> GUI sample, but the latter one is really complex. Ask further
>> questions if you need - maybe I will port to car selector sample to
>> union if I have time :) A bug concerning the values when switching the
>> select box for example was fixed *yesterday* and is so only available
>> in CVS.
>
> Have you (or anyone else) noticed a bug with action widgets inside a
> union? The behaviour I'm seeing is that they always cause the form to be
> submitted, rather than just updated. It's annoying because I'm trying to
> create a popup detail area which contains a button to hide itself, but
> instead of hiding the detail area the button submits the entire form. Am
> I just doing something dumb, or is this a bug in CForms?
Is an action widget not always a submit button by default? Only the
behaviour on server side is different. I guess the above is unrelated to
union. You would have to customize the forms stylesheets for your
special type of action. I did it myself with an fi:styling/@type='link'.
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Show/Hide Widgets
Posted by Vilya Harvey <vi...@lineone.net>.
Joerg Heinicke wrote:
> This is possible using the union widget. I did it myself on Friday. The
> resources I used were http://wiki.cocoondev.org/Wiki.jsp?page=TimLarson
> and the form model GUI sample, but the latter one is really complex. Ask
> further questions if you need - maybe I will port to car selector sample
> to union if I have time :) A bug concerning the values when switching
> the select box for example was fixed *yesterday* and is so only
> available in CVS.
Have you (or anyone else) noticed a bug with action widgets inside a union?
The behaviour I'm seeing is that they always cause the form to be submitted,
rather than just updated. It's annoying because I'm trying to create a popup
detail area which contains a button to hide itself, but instead of hiding
the detail area the button submits the entire form. Am I just doing
something dumb, or is this a bug in CForms?
Thanks for any help!
Vil.
--
__
o| _. / \|o._ _ _ ._ _ ._ _ _|_
\/ ||\/(_|| (|/||| |(/_(_)| |(/_o| |(/_ |_
/ \__
http://website.lineone.net/~vilya
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Show/Hide Widgets
Posted by Joerg Heinicke <jo...@gmx.de>.
On 27.06.2004 15:21, oceatoon wrote:
> Hi everyone
>
> I would like to be able to show/hide widgets according to certain events
> (Ex: in the Car Selector sample in the Forms block, I would like to show
> the car type widget only once the make has been choosen).
>
> Does anybody know how this is possible, do I have to change template files
> removing the concerned widget or is there a show/hide attribute???
>
> Thanks for your thoughts.
This is possible using the union widget. I did it myself on Friday. The
resources I used were http://wiki.cocoondev.org/Wiki.jsp?page=TimLarson
and the form model GUI sample, but the latter one is really complex. Ask
further questions if you need - maybe I will port to car selector sample
to union if I have time :) A bug concerning the values when switching
the select box for example was fixed *yesterday* and is so only
available in CVS.
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org