You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by roy huang <li...@hotmail.com> on 2004/04/05 12:28:49 UTC
Re: disabling widgets
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107792005324520&w=2
In this link,Sylvain suggest 3 states for a widget,I think it's a good idea.
Today I want to hide an action under some condition ,but I just can't if I don't modify the forms-field-styling.xsl.
I use a transformer to generate different cocoon form define under different condition,but the widget is always there(type may be different).So in style xml I can always use widget like that:
<ft:widget id="edit">
</ft:widget>
But if I remove the widget from the form define file,display will generate an error about 'Widget with id "***" does not exist in the form container'.I thought an afternoon and believe I must modify forms-field-styling.xsl to do the job,but I don't like this method.(see also:http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107774469108519&w=2)
Yes,content and display should separate ,but if just the content indicate display it or not?The Cocoon Forms proposal contain <fd:choice> (http://wiki.cocoondev.org/Wiki.jsp?page=WoodyScratchpad), I think this proposal is similar to what I am doing now.So if the inline widget doesn't exist and displaytemplate use it ,it will generate the same error.
Solution suggestion:
1.Do not generate error if a widget not exist ,just not render or ignore it.Of course ,this can turn on and off by parameter.
2.Sylvain's suggest,3 states for a widget.this state is an attribute of a widget define,we can modify it by flow or own transformer.
WDYT?
Roy Huang
Re: disabling widgets
Posted by Christopher Oliver <re...@verizon.net>.
Bruno Dumon wrote:
>On Tue, 2004-04-06 at 18:19, Christopher Oliver wrote:
>
>
>>Bruno Dumon wrote:
>><snip>
>>
>>>>
>>>>
>>>For the generator-approach, a good starting point would be to commit it
>>>to CVS and add or change an example to show how it works.
>>>
>>>
>>>
>>>
>>>
>>I've done this for the V2 flowscript sample.
>>
>>
>
>Cool, hadn't paid attention to that yet. Are there still any open issues
>or incompatibilities to be aware of?
>
>
>
I had to put in hack to insert the styling element into the widget
element. Maybe someone can think of better way. Class, Union, Struct
aren't supported yet.
Chris
Re: disabling widgets
Posted by Bruno Dumon <br...@outerthought.org>.
On Tue, 2004-04-06 at 18:19, Christopher Oliver wrote:
> Bruno Dumon wrote:
>
> >On Mon, 2004-04-05 at 13:28, Sylvain Wallez wrote:
> ><snip/>
> >
> >
> >>So, I propose the following changes to Cocoon forms:
> >>- add a state to widgets (enabled/disabled/hidden).
> >>- move to a generator approach.
> >>
> >>WDYT?
> >>
> >>
> >
> >For the generator-approach, a good starting point would be to commit it
> >to CVS and add or change an example to show how it works.
> >
> >
> >
> I've done this for the V2 flowscript sample.
Cool, hadn't paid attention to that yet. Are there still any open issues
or incompatibilities to be aware of?
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: disabling widgets
Posted by Christopher Oliver <re...@verizon.net>.
Bruno Dumon wrote:
>On Mon, 2004-04-05 at 13:28, Sylvain Wallez wrote:
><snip/>
>
>
>>So, I propose the following changes to Cocoon forms:
>>- add a state to widgets (enabled/disabled/hidden).
>>- move to a generator approach.
>>
>>WDYT?
>>
>>
>
>For the generator-approach, a good starting point would be to commit it
>to CVS and add or change an example to show how it works.
>
>
>
I've done this for the V2 flowscript sample.
Regards,
Chris
Re: disabling widgets
Posted by Bruno Dumon <br...@outerthought.org>.
On Mon, 2004-04-05 at 13:28, Sylvain Wallez wrote:
<snip/>
>
> So, I propose the following changes to Cocoon forms:
> - add a state to widgets (enabled/disabled/hidden).
> - move to a generator approach.
>
> WDYT?
For the generator-approach, a good starting point would be to commit it
to CVS and add or change an example to show how it works.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: disabling widgets
Posted by Tim Larson <ti...@keow.org>.
On Thu, Apr 08, 2004 at 07:55:44AM -0400, Vadim Gritsenko wrote:
> Tim Larson wrote:
> >We need to be able to specify the hidden state and the
> >selection of {both|output|input|neither} both statically in
>
> +1
>
> >the widget definitions and dynamically via flowscript, Java,
> >binding, and event handling, but not via the view, of course.
>
> I don't see a necessity to provide so much flexibility.
Ok, maybe not all of it yet, but I do have a use case right
now for being able to dynamically switch between the normal
"both" mode and "output"-only mode. In the Form Model GUI
I want to default to showing the widget definitions with an
easy-on-the-eyes read-only summary, and for each widget
definition have a button/checkbox/tab/whatever to switch
just the selected widget definition(s) to collections of
editable input widgets like the sample has now.
We could solve this several ways:
* Make the both|output|etc. setting dynamically settable as
suggested above.
* Introduce "alias" widgets to hold configuration, while
referencing other widgets for the data, and then wrap
alternate "both" and "output" alias widgets in a "choice"
widget to control what is sent to the view layer.
* (Hacky) Have the view layer contain a hidden input for
these output widgets so that readFromRequest does not
reset these output-styled field widgets to null.
* (Non-portable, but sometimes a good option) Only use
client-side tools (js/xul/etc.) to switch between modes.
WDYT
--Tim Larson
Re: disabling widgets
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Tim Larson wrote:
>We need to be able to specify the hidden state and the
>selection of {both|output|input|neither} both statically in
>
>
+1
>the widget definitions and dynamically via flowscript, Java,
>binding, and event handling, but not via the view, of course.
>
>
I don't see a necessity to provide so much flexibility.
Vadim
Re: disabling widgets
Posted by Tim Larson <ti...@keow.org>.
On Mon, Apr 05, 2004 at 01:28:42PM +0200, Sylvain Wallez wrote:
> So, I propose the following changes to Cocoon forms:
> - add a state to widgets (enabled/disabled/hidden).
> - move to a generator approach.
No official comment on the generator approach since I have not
yet tried it, but it looks pretty good from the descriptions I
have seen. I was just getting ready to make a proposal about
widget states, so I will just copy it below:
Remember the "direction" attribute in the binding? I think we
need something like that here, but with a different name that
fits this context. Here are the options I propose for this attr:
(Note: Not proposing names, just listing the semantics we need.)
both
Send value and receive value from user
This is the normal case for a widget.
output
Send value, but do not receive value from user.
This disables request parameter processing for the widget
and all of its child widgets, like what we currently use
the "output" widget for. This would add the feature to
all widgets, so for example you could have a read-only
table driven by an "output" repeater.
input
Send no value, but receive value from user.
This is for passwords or other sensitive values where we
do not want to echo the value back into the users's form.
neither
Do not send value, and do not receive value from user.
This is for internal values that we do not want to send
to the user, not even hidden, but where we still want to
make use of the other features of widgets, such as event
handling, validation, binding, etc.
We may also need another separate attribute to handle hiding:
hidden
Suppress display of value.
Hiding is actually orthogonal to the settings above,
because depending on the use-case we may want to pair
it with any of "both", "output", or "input" widgets.
For example, a hidden tab-state would be probably be a
"both" field, a fixed-size repeater may send the size
as an "output" field, and a widget recording what
triggered a submit may be an "input" field.
We need to be able to specify the hidden state and the
selection of {both|output|input|neither} both statically in
the widget definitions and dynamically via flowscript, Java,
binding, and event handling, but not via the view, of course.
--Tim Larson
Widget Labels, Re: disabling widgets
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Sylvain Wallez wrote:
> Vadim Gritsenko wrote:
>
>> Also, what do you think about something to allow generation of
>> <label>s? Currently, <widget-label> does not produce any label at all...
>
>
> Actually, that's not a generator/transformer problem, but something
> wrong with <ft:widget-label>. It should produce a <fi:label> tag
> containing what it produces today. This then allows the styling to
> generate the correct <label> tags.
So it is something which is not implemented yet? If I get some time I'll
look into implementing this.
Vadim
Re: disabling widgets
Posted by Sylvain Wallez <sy...@apache.org>.
Vadim Gritsenko wrote:
> Sylvain Wallez wrote:
>
>> Vadim Gritsenko wrote:
>>
>>> Sylvain Wallez wrote:
>>>
>>>> Now, as I mentioned already [1], I started using the generator
>>>> approach
>>>> to form templates, using the implementation of "wt:" statements using
>>>> JXMacro provided by Chris [2]. And this approach is very powerful,
>>>> as it
>>>> allows complex conditional form layout without requiring the
>>>> introduction of yet-another-control-structure-markup in the "wt:"
>>>> namespace.
>>>>
>>>> Introducing the widget states would allow these conditions to be
>>>> computed with the form's own state rather than using some separate
>>>> flow
>>>> values.
>>>>
>>>> So, I propose the following changes to Cocoon forms:
>>>> - add a state to widgets (enabled/disabled/hidden).
>>>>
>>>>
>>>
>>> Assuming this state will be available during binding, as well as in
>>> form... +1. But, this will require some kind of "wt:" control markup
>>> anyway... Given simple example:
>>> <table><tr><td><wt:widget-label id="x"/></td><td><wt:widget
>>> id="x"/></td></tr></table>
>>>
>>> There is a need to disable whole table, it's not enough to take out
>>> widget only.
>>
>>
>> This is exactly why a generator approach is needed :
>
>
> Well, of course it will work with generator. But what if generator can
> not be used in this scenario (xslt processing required; use of other
> template engine; something else), what then? Either it should be also
> possible with JXTemplateTransformer, or FormsTransformer to be
> extended, or (ideally) both of those.
The source of your generator can be a "cocoon:". This has the benefit
(if the "cocoon:" is cacheable) that you don't necessarily have
recompile the template like what would be needed with a transformer.
> Also, what do you think about something to allow generation of
> <label>s? Currently, <widget-label> does not produce any label at all...
Actually, that's not a generator/transformer problem, but something
wrong with <ft:widget-label>. It should produce a <fi:label> tag
containing what it produces today. This then allows the styling to
generate the correct <label> tags.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: disabling widgets
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Sylvain Wallez wrote:
> Vadim Gritsenko wrote:
>
>> Sylvain Wallez wrote:
>>
>>> Now, as I mentioned already [1], I started using the generator approach
>>> to form templates, using the implementation of "wt:" statements using
>>> JXMacro provided by Chris [2]. And this approach is very powerful,
>>> as it
>>> allows complex conditional form layout without requiring the
>>> introduction of yet-another-control-structure-markup in the "wt:"
>>> namespace.
>>>
>>> Introducing the widget states would allow these conditions to be
>>> computed with the form's own state rather than using some separate flow
>>> values.
>>>
>>> So, I propose the following changes to Cocoon forms:
>>> - add a state to widgets (enabled/disabled/hidden).
>>>
>>>
>>
>> Assuming this state will be available during binding, as well as in
>> form... +1. But, this will require some kind of "wt:" control markup
>> anyway... Given simple example:
>> <table><tr><td><wt:widget-label id="x"/></td><td><wt:widget
>> id="x"/></td></tr></table>
>>
>> There is a need to disable whole table, it's not enough to take out
>> widget only.
>
>
>
> This is exactly why a generator approach is needed :
Well, of course it will work with generator. But what if generator can
not be used in this scenario (xslt processing required; use of other
template engine; something else), what then? Either it should be also
possible with JXTemplateTransformer, or FormsTransformer to be extended,
or (ideally) both of those.
Also, what do you think about something to allow generation of <label>s?
Currently, <widget-label> does not produce any label at all...
Vadim
Re: disabling widgets
Posted by Sylvain Wallez <sy...@apache.org>.
Vadim Gritsenko wrote:
> Sylvain Wallez wrote:
>
>> Now, as I mentioned already [1], I started using the generator approach
>> to form templates, using the implementation of "wt:" statements using
>> JXMacro provided by Chris [2]. And this approach is very powerful, as it
>> allows complex conditional form layout without requiring the
>> introduction of yet-another-control-structure-markup in the "wt:"
>> namespace.
>>
>> Introducing the widget states would allow these conditions to be
>> computed with the form's own state rather than using some separate flow
>> values.
>>
>> So, I propose the following changes to Cocoon forms:
>> - add a state to widgets (enabled/disabled/hidden).
>>
>>
>
> Assuming this state will be available during binding, as well as in
> form... +1. But, this will require some kind of "wt:" control markup
> anyway... Given simple example:
> <table><tr><td><wt:widget-label id="x"/></td><td><wt:widget
> id="x"/></td></tr></table>
>
> There is a need to disable whole table, it's not enough to take out
> widget only.
This is exactly why a generator approach is needed :
<jx:choose>
<jx:when test="${currentWidget.getChild("x").isDisabled()}">
<table>
<tr>
<td><wt:widget-label id="x"/></td>
<td><wt:widget id="x"/></td>
</tr>
</table>
</jx:when>
<jx:otherwise>
This data is currently not available.
</jx:otherwise>
</jx:choose>
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: disabling widgets
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Sylvain Wallez wrote:
>Now, as I mentioned already [1], I started using the generator approach
>to form templates, using the implementation of "wt:" statements using
>JXMacro provided by Chris [2]. And this approach is very powerful, as it
>allows complex conditional form layout without requiring the
>introduction of yet-another-control-structure-markup in the "wt:" namespace.
>
>Introducing the widget states would allow these conditions to be
>computed with the form's own state rather than using some separate flow
>values.
>
>So, I propose the following changes to Cocoon forms:
>- add a state to widgets (enabled/disabled/hidden).
>
>
Assuming this state will be available during binding, as well as in
form... +1. But, this will require some kind of "wt:" control markup
anyway... Given simple example:
<table><tr><td><wt:widget-label id="x"/></td><td><wt:widget
id="x"/></td></tr></table>
There is a need to disable whole table, it's not enough to take out
widget only.
>- move to a generator approach.
>
>
+1.
Vadim
>WDYT?
>
>Sylvain
>[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108072698303323&w=2
>[2] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107332516118153&w=2
>
Re: disabling widgets
Posted by Sylvain Wallez <sy...@apache.org>.
Antonio Gallardo wrote:
>Sylvain Wallez dijo:
>
>
>>So, I propose the following changes to Cocoon forms:
>>- add a state to widgets (enabled/disabled/hidden).
>>
>>
>
>It maybe good. Can reach the same result using another pipeline to
>generate the "form definition" file?
>
>
Do you mean disabling fields by using dynamically-generated forms? This
isn't enough, as we need to be able to change the state of widgets
within the interaction of a user with a form instance, e.g. depending on
the entered values.
>>- move to a generator approach.
>>
>>
>
>Can we still use JXTemplateGenerator expression inside? AFAIK, this is a very important issue.
>
>
I'm currently using JX macros which, of course, use JXTemplateGenerator ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: disabling widgets
Posted by Antonio Gallardo <ag...@agssa.net>.
Sylvain Wallez dijo:
> So, I propose the following changes to Cocoon forms:
> - add a state to widgets (enabled/disabled/hidden).
It maybe good. Can reach the same result using another pipeline to
generate the "form definition" file?
> - move to a generator approach.
Can we still use JXTemplateGenerator expression inside? AFAIK, this is a
very important issue.
Best Regards,
Antonio Gallardo
Re: disabling widgets
Posted by Sylvain Wallez <sy...@apache.org>.
Upayavira wrote:
> Leon Widdershoven wrote:
>
>>
>>> - move to a generator approach.
>>
>>
>>
>> Do you mean generator-only approach? I think that would limit the
>> options of the users quite a bit (and I am one of those). I actually
>> like the pipeline
>> approach so that you can build your XML tree dynamically; if one
>> would move
>> to a generator only approach other generator-only functionalities
>> (xsp, though
>> that appears to be deprecated) can not really be used anymore.
>>
>> As you notice I am not well enough at home in cocoon core matters to
>> really have an opinion, but two months ago when I started using
>> cocoon (and I am working full time with cocoon-2.1.4) the fact that
>> the xsp was a generator only brought me a lot of trouble so I have a
>> bit of a phobia about that.
>
>
> Sylvain is not proposing to scrap pipelining, just to merge a couple
> of stages. At present, in CForms, you can have:
>
> JXTemplateGenerator->FormTransformer->XSLT->Serialise
>
> What is being proposed is to use JXMacros in JXTemplateGenerator to
> implement the functionality of the FormTransformer, so you get:
>
> JXTemplateGenerator->XSLT->Serialise
>
> So, hopefully this scares you less. The template that is being worked
> with is very much an XML one - XML to HTML transformation remains
> steadfastly with XSLT.
Exactly. This idea came from the fact that the form state participates
in defining the page layout through widget states (in the global
meaning, e.g. when a repeater is empty).
And if this isn't taken into account at the generator level (a dynamic
one, like JXTemplate), this leads to defining control structure
statements in the markup handled by a transformer. And this leads to
defining a myriad of similar-yet-different markups all over the place,
for a result that cannot achieve the expressional power of a single
dynamic generator (be it JXTemplate or XSP).
In short, transformers should not be used to define the document
_structure_.
And believe me, I love pipelines ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: disabling widgets
Posted by Upayavira <uv...@upaya.co.uk>.
Antonio Gallardo wrote:
>Upayavira dijo:
>
>
>>Leon Widdershoven wrote:
>>
>>
>>
>>>>- move to a generator approach.
>>>>
>>>>
>>>Do you mean generator-only approach? I think that would limit the
>>>options of the users quite a bit (and I am one of those). I actually
>>>like the pipeline
>>>approach so that you can build your XML tree dynamically; if one would
>>>move
>>>to a generator only approach other generator-only functionalities
>>>(xsp, though
>>>that appears to be deprecated) can not really be used anymore.
>>>
>>>As you notice I am not well enough at home in cocoon core matters to
>>>really have an opinion, but two months ago when I started using cocoon
>>>(and I am working full time with cocoon-2.1.4) the fact that the xsp
>>>was a generator only brought me a lot of trouble so I have a bit of a
>>>phobia about that.
>>>
>>>
>>Sylvain is not proposing to scrap pipelining, just to merge a couple of
>>stages. At present, in CForms, you can have:
>>
>>JXTemplateGenerator->FormTransformer->XSLT->Serialise
>>
>>What is being proposed is to use JXMacros in JXTemplateGenerator to
>>implement the functionality of the FormTransformer, so you get:
>>
>>JXTemplateGenerator->XSLT->Serialise
>>
>>So, hopefully this scares you less. The template that is being worked
>>with is very much an XML one - XML to HTML transformation remains
>>steadfastly with XSLT.
>>
>>
>
>Will be also able to use the JXTemplateGenerator without CForms?
>
>
I think it is more a question of whether you will be able to use
JXTemplateGenerator without flow. They are (or were) quite tied to each
other.
But there is no specific connection between CForms and the
JXTemplateGenerator.
Upayavira
Re: disabling widgets
Posted by Antonio Gallardo <ag...@agssa.net>.
Upayavira dijo:
> Leon Widdershoven wrote:
>
>>
>>> - move to a generator approach.
>>
>>
>> Do you mean generator-only approach? I think that would limit the
>> options of the users quite a bit (and I am one of those). I actually
>> like the pipeline
>> approach so that you can build your XML tree dynamically; if one would
>> move
>> to a generator only approach other generator-only functionalities
>> (xsp, though
>> that appears to be deprecated) can not really be used anymore.
>>
>> As you notice I am not well enough at home in cocoon core matters to
>> really have an opinion, but two months ago when I started using cocoon
>> (and I am working full time with cocoon-2.1.4) the fact that the xsp
>> was a generator only brought me a lot of trouble so I have a bit of a
>> phobia about that.
>
> Sylvain is not proposing to scrap pipelining, just to merge a couple of
> stages. At present, in CForms, you can have:
>
> JXTemplateGenerator->FormTransformer->XSLT->Serialise
>
> What is being proposed is to use JXMacros in JXTemplateGenerator to
> implement the functionality of the FormTransformer, so you get:
>
> JXTemplateGenerator->XSLT->Serialise
>
> So, hopefully this scares you less. The template that is being worked
> with is very much an XML one - XML to HTML transformation remains
> steadfastly with XSLT.
Will be also able to use the JXTemplateGenerator without CForms?
Best Regards,
Antonio Gallardo
Re: disabling widgets
Posted by Upayavira <up...@fwbo.org>.
Leon Widdershoven wrote:
>
>> - move to a generator approach.
>
>
> Do you mean generator-only approach? I think that would limit the
> options of the users quite a bit (and I am one of those). I actually
> like the pipeline
> approach so that you can build your XML tree dynamically; if one would
> move
> to a generator only approach other generator-only functionalities
> (xsp, though
> that appears to be deprecated) can not really be used anymore.
>
> As you notice I am not well enough at home in cocoon core matters to
> really have an opinion, but two months ago when I started using cocoon
> (and I am working full time with cocoon-2.1.4) the fact that the xsp
> was a generator only brought me a lot of trouble so I have a bit of a
> phobia about that.
Sylvain is not proposing to scrap pipelining, just to merge a couple of
stages. At present, in CForms, you can have:
JXTemplateGenerator->FormTransformer->XSLT->Serialise
What is being proposed is to use JXMacros in JXTemplateGenerator to
implement the functionality of the FormTransformer, so you get:
JXTemplateGenerator->XSLT->Serialise
So, hopefully this scares you less. The template that is being worked
with is very much an XML one - XML to HTML transformation remains
steadfastly with XSLT.
Hope that helps.
Upayavira
Re: disabling widgets
Posted by Leon Widdershoven <qa...@dds.nl>.
> - move to a generator approach.
Do you mean generator-only approach? I think that would limit the options of
the users quite a bit (and I am one of those). I actually like the pipeline
approach so that you can build your XML tree dynamically; if one would move
to a generator only approach other generator-only functionalities (xsp, though
that appears to be deprecated) can not really be used anymore.
As you notice I am not well enough at home in cocoon core matters to really
have an opinion, but two months ago when I started using cocoon (and I am
working full time with cocoon-2.1.4) the fact that the xsp was a generator
only brought me a lot of trouble so I have a bit of a phobia about that.
Regards,
Leon Widdershoven
Re: disabling widgets
Posted by Sylvain Wallez <sy...@apache.org>.
roy huang wrote:
>http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107792005324520&w=2
>In this link,Sylvain suggest 3 states for a widget,I think it's a good idea.
>Today I want to hide an action under some condition ,but I just can't if I don't modify the forms-field-styling.xsl.
>I use a transformer to generate different cocoon form define under different condition,but the widget is always there(type may be different).So in style xml I can always use widget like that:
> <ft:widget id="edit">
> </ft:widget>
>But if I remove the widget from the form define file,display will generate an error about 'Widget with id "***" does not exist in the form container'.I thought an afternoon and believe I must modify forms-field-styling.xsl to do the job,but I don't like this method.(see also:http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107774469108519&w=2)
>
>Yes,content and display should separate ,but if just the content indicate display it or not?The Cocoon Forms proposal contain <fd:choice> (http://wiki.cocoondev.org/Wiki.jsp?page=WoodyScratchpad), I think this proposal is similar to what I am doing now.So if the inline widget doesn't exist and displaytemplate use it ,it will generate the same error.
>
>Solution suggestion:
>1.Do not generate error if a widget not exist ,just not render or ignore it.Of course ,this can turn on and off by parameter.
>
>
I don't like this, as it makes finding typo errors very difficult. The
view must be strict about widget identifiers.
>2.Sylvain's suggest,3 states for a widget.this state is an attribute of a widget define,we can modify it by flow or own transformer.
>
>
Yes, this state would be an attribute of the widget, that can be
modified by the flow and event handlers, but not by the transformer. The
transformer should be able to react on the widget's state (i.e. ignore
it if it's in hidden state), but, being part of the view, should not
modify the form's state. This is the role of the controller.
Now, as I mentioned already [1], I started using the generator approach
to form templates, using the implementation of "wt:" statements using
JXMacro provided by Chris [2]. And this approach is very powerful, as it
allows complex conditional form layout without requiring the
introduction of yet-another-control-structure-markup in the "wt:" namespace.
Introducing the widget states would allow these conditions to be
computed with the form's own state rather than using some separate flow
values.
So, I propose the following changes to Cocoon forms:
- add a state to widgets (enabled/disabled/hidden).
- move to a generator approach.
WDYT?
Sylvain
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108072698303323&w=2
[2] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107332516118153&w=2
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }