Re: disabling widgets
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
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
Bruno Dumon wrote: On Tue, 2004-04-06 at 18:19, Christopher Oliver wrote: Bruno Dumon wrote: 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
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: > > > > > > > >>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 [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: disabling widgets
Bruno Dumon wrote: On Mon, 2004-04-05 at 13:28, 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. 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
On Mon, 2004-04-05 at 13:28, 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. > > 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 [EMAIL PROTECTED] [EMAIL PROTECTED]
Widget Labels, Re: disabling widgets
Sylvain Wallez wrote: Vadim Gritsenko wrote: Also, what do you think about something to allow generation of s? Currently, does not produce any label at all... Actually, that's not a generator/transformer problem, but something wrong with . It should produce a tag containing what it produces today. This then allows the styling to generate the correct 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
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
Re: disabling widgets
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:
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
s? Currently, does not produce any label at all...
Actually, that's not a generator/transformer problem, but something
wrong with . It should produce a tag
containing what it produces today. This then allows the styling to
generate the correct 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
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: 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 s? Currently, does not produce any label at all... Vadim
Re: disabling widgets
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
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
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
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:
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 :
This data is currently not available.
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
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
- 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
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: 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
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
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
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:
>
>
>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
>(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 }
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: 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 (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
Jeremy Quinn wrote:
On 25 Feb 2004, at 12:32, Reinhard Poetz wrote:
-Original Message-
From: Antonio Gallardo [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 25, 2004 1:28 PM
To: [EMAIL PROTECTED]
Subject: Re: disabling widgets
Jeremy Quinn dijo:
Hi All
I have a booleanfield widget, that needs to be disabled
under certain
conditions.
pseudo-code :
if ( album.scenarios.size() > 0 ) {
disable ( album.publishable );
}
ie. the album.publishable value needs to be in the form, but should
not be alterable by the user.
Is there a way of doing this in Cocoon Forms ?
Another approach (not tested by me, but maybe works) is using
the JXTemplateGenerator. There is a tag that can be
use to show/hide controls in the rendered page.
IIRC Sylvain extendet the showform function so that you can pass the
objects to the view layer. You could either use Antonio's suggestion or
you add a parameter to the widget styling.
Yep. Form.showForm has the same parameters as cocoon.sendPageAndWait(),
as there's no reason not to be able to pass some additional application
data to the view when using forms.
So what you are saying is this? :
1. add appropriate JX-Template conditional statement to my
booleanfield widget
which will add @readonly="readonly" to the wi:styling if the
condition is met
2. pass the required BizData to the showform method as required by
the conditional above
3. use JX-Generator instead of the FileGenerator in my Woody
pipeline to pre-process
my Woody-Template before it goes to the Woody Transformer
Or also, use the woody template implementation using JX macros sent by
Christopher a while ago. I started using this approach this week, which
I needed that for two purposes:
- display a "no items" text when a repeater is empty instead of an empty
table with only headers,
- implement a very specific styling for an output widget: it contains
the ID of a node in a tree, and I needed to display the path of this node.
Conclusion: *it rocks*! Being able to access the form model within the
generator allows to very easily build sophisticated presentations for a
form.
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
Antonio Gallardo wrote:
Reinhard Poetz dijo:
Sorry, I don't like this client-side approach.
We have to find something better because sometimes the 'presentation
state' of a widget can depend on the 'application state'. Flowscript as
controller should have access to both.
Hi Reinhard:
How manage a dynamic "show/hide a control" in a page without doing a
round-trip to the server?
Based on some observation while no-tech oriented users filled HTML forms.
It makes clear to me that they don't liked the round-trip to the server.
It was confusing to him! It is clear a non-conventional interface. Also it
waste time, no matter how fast the connection (including the server) are.
The observation was related to calculated widgets.
I think this is a similar case, because the show/hide control is just a
rendering page issue. Of course, you can add add additional parameters to
reflect the current "application state" and let the page have the right
behavior. If we suspect that it can be a security concerns, there is a
gold rule:
"Anything returned from the client must the checked again, when the
control return to the Flow (serversided)."
(jumping in late) I don't think it's *only* a rendering issue.
A colleague of mine recently asked me how to change widgets availability
in a form depending on the user's role or application state such as when
a form goes through different people and/or states in a workflow.
The purpose here isn't dynamic interaction within an interaction with a
single user, but allow to "configure" the form before it is displayed to
the user.
I came to 3 possible states for a widget:
- enabled: what we have today
- disabled: the widget behaves like an output and it doesn't read its
value from the request (solves the "Anything returned..." below).
- hidden: the widget doesn't display itself.
A disabled composite widget (e.g. a repeater) doesn't call
readFromRequest() on its children. Similarily, the woody transformer
should take into account hidden composite widget references (e.g.
by ignoring their content.
WDYT?
Sylvain (first post from my Mac!!)
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: disabling widgets
snip
> > >>> I have a booleanfield widget, that needs to be disabled
> >> under certain
> >>> conditions.
> >>>
> >>> pseudo-code :
> >>>
> >>> if ( album.scenarios.size() > 0 ) {
> >>> disable ( album.publishable );
> >>> }
I have solved this in a slightly hacky way
woody-model:
. . .
label.publishable
hint.publishable
label.scenarios
hint.scenarios
. . .
woody-binding:
. . .
. . .
woody-template:
XSLT:
this.checked=this.defaultChecked;alert('This Album is
featured in a Scenario, it cannot be made Private
anymore.');
checked
It works for now . but is very application specific, and I would
not want to do anything more complicated using this technique.
Thanks
regards Jeremy
smime.p7s
Description: S/MIME cryptographic signature
Re: disabling widgets
On 25 Feb 2004, at 18:28, [EMAIL PROTECTED] wrote:
Jeremy Quinn <[EMAIL PROTECTED]> wrote on 02/25/2004 06:28:05
AM:
>
> On 25 Feb 2004, at 12:32, Reinhard Poetz wrote:
>
> >
> >
> >> -Original Message-
> >> From: Antonio Gallardo [mailto:[EMAIL PROTECTED]
> >> Sent: Wednesday, February 25, 2004 1:28 PM
> >> To: [EMAIL PROTECTED]
> >> Subject: Re: disabling widgets
> >>
> >>
> >> Jeremy Quinn dijo:
> >>> Hi All
> >>>
> >>> I have a booleanfield widget, that needs to be disabled
> >> under certain
> >>> conditions.
> >>>
> >>> pseudo-code :
> >>>
> >>> if ( album.scenarios.size() > 0 ) {
> >>> disable ( album.publishable );
> >>> }
> >>>
> >>> ie. the album.publishable value needs to be in the form, but
should
> >>> not be alterable by the user.
> >>>
> >>> Is there a way of doing this in Cocoon Forms ?
> >>
> >> Another approach (not tested by me, but maybe works) is using
> >> the JXTemplateGenerator. There is a tag that can be
> >> use to show/hide controls in the rendered page.
> >
> > IIRC Sylvain extendet the showform function so that you can pass
the
> > objects to the view layer. You could either use Antonio's
suggestion or
> > you add a parameter to the widget styling.
>
> So what you are saying is this? :
>
> 1. add appropriate JX-Template conditional statement to my
> booleanfield widget
> which will add @readonly="readonly" to the wi:styling if the
> condition is met
> 2. pass the required BizData to the showform method as required
by the
> conditional above
> 3. use JX-Generator instead of the FileGenerator in my Woody
pipeline
> to pre-process
> my Woody-Template before it goes to the Woody Transformer
>
> > My question: Is this the way we recommend or do we want to have
widgets
> > an interface which can be used in order change presentation state?
>
> It is with much joy that I find @readonly is ignored by both Mozilla
> and Safari (hoo-bloody-ray!! )
have you considered adding @onclick instead, i.e.,
onclick="this.checked=this.defaultChecked" ?
Just a thought...
Nice idea, thanks
regards Jeremy
smime.p7s
Description: S/MIME cryptographic signature
Re: disabling widgets
Jeremy Quinn <[EMAIL PROTECTED]> wrote
on 02/25/2004 06:28:05 AM:
>
> On 25 Feb 2004, at 12:32, Reinhard Poetz wrote:
>
> >
> >
> >> -Original Message-
> >> From: Antonio Gallardo [mailto:[EMAIL PROTECTED]
> >> Sent: Wednesday, February 25, 2004 1:28 PM
> >> To: [EMAIL PROTECTED]
> >> Subject: Re: disabling widgets
> >>
> >>
> >> Jeremy Quinn dijo:
> >>> Hi All
> >>>
> >>> I have a booleanfield widget, that needs to be disabled
> >> under certain
> >>> conditions.
> >>>
> >>> pseudo-code :
> >>>
> >>> if ( album.scenarios.size() > 0 ) {
> >>> disable ( album.publishable
);
> >>> }
> >>>
> >>> ie. the album.publishable value needs to be in the form,
but should
> >>> not be alterable by the user.
> >>>
> >>> Is there a way of doing this in Cocoon Forms ?
> >>
> >> Another approach (not tested by me, but maybe works) is using
> >> the JXTemplateGenerator. There is a tag that
can be
> >> use to show/hide controls in the rendered page.
> >
> > IIRC Sylvain extendet the showform function so that you can pass
the
> > objects to the view layer. You could either use Antonio's suggestion
or
> > you add a parameter to the widget styling.
>
> So what you are saying is this? :
>
> 1. add appropriate JX-Template conditional statement
to my
> booleanfield widget
> which will add @readonly="readonly"
to the wi:styling if the
> condition is met
> 2. pass the required BizData to the showform method as
required by the
> conditional above
> 3. use JX-Generator instead of the FileGenerator in my
Woody pipeline
> to pre-process
> my Woody-Template before it goes to the Woody
Transformer
>
> > My question: Is this the way we recommend or do we want to have
widgets
> > an interface which can be used in order change presentation state?
>
> It is with much joy that I find @readonly is ignored by both Mozilla
> and Safari (hoo-bloody-ray!! )
have you considered adding @onclick instead, i.e.,
?
Just a thought...
--Michael
Re: disabling widgets
On 25 Feb 2004, at 14:52, Guido Casper wrote: Jeremy Quinn wrote: It is with much joy that I find @readonly is ignored by both Mozilla and Safari (hoo-bloody-ray!! ) Try @disabled instead. Unfortunately AFAIU (according to the spec at www.w3.org) @disabled input fields do not get posted to the server. So you'd still be hacking . Thanks for the suggestion anyway ;) regards Jeremy smime.p7s Description: S/MIME cryptographic signature
Re: disabling widgets
Jeremy Quinn wrote: It is with much joy that I find @readonly is ignored by both Mozilla and Safari (hoo-bloody-ray!! ) Try @disabled instead. Guido
Re: disabling widgets
On 25 Feb 2004, at 12:32, Reinhard Poetz wrote:
-Original Message-
From: Antonio Gallardo [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 25, 2004 1:28 PM
To: [EMAIL PROTECTED]
Subject: Re: disabling widgets
Jeremy Quinn dijo:
Hi All
I have a booleanfield widget, that needs to be disabled
under certain
conditions.
pseudo-code :
if ( album.scenarios.size() > 0 ) {
disable ( album.publishable );
}
ie. the album.publishable value needs to be in the form, but should
not be alterable by the user.
Is there a way of doing this in Cocoon Forms ?
Another approach (not tested by me, but maybe works) is using
the JXTemplateGenerator. There is a tag that can be
use to show/hide controls in the rendered page.
IIRC Sylvain extendet the showform function so that you can pass the
objects to the view layer. You could either use Antonio's suggestion or
you add a parameter to the widget styling.
So what you are saying is this? :
1. add appropriate JX-Template conditional statement to my
booleanfield widget
which will add @readonly="readonly" to the wi:styling if the
condition is met
2. pass the required BizData to the showform method as required by the
conditional above
3. use JX-Generator instead of the FileGenerator in my Woody pipeline
to pre-process
my Woody-Template before it goes to the Woody Transformer
My question: Is this the way we recommend or do we want to have widgets
an interface which can be used in order change presentation state?
It is with much joy that I find @readonly is ignored by both Mozilla
and Safari (hoo-bloody-ray!! )
So while the standards are not implemented on the browsers, going to a
lot of effort to add this to Woody will be a waste of time IMHO,
because you would need to hack the widget tags in an
application-specific way.
regards Jeremy
smime.p7s
Description: S/MIME cryptographic signature
RE: disabling widgets
> -Original Message-
> From: Antonio Gallardo [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, February 25, 2004 1:28 PM
> To: [EMAIL PROTECTED]
> Subject: Re: disabling widgets
>
>
> Jeremy Quinn dijo:
> > Hi All
> >
> > I have a booleanfield widget, that needs to be disabled
> under certain
> > conditions.
> >
> > pseudo-code :
> >
> > if ( album.scenarios.size() > 0 ) {
> > disable ( album.publishable );
> > }
> >
> > ie. the album.publishable value needs to be in the form, but should
> > not be alterable by the user.
> >
> > Is there a way of doing this in Cocoon Forms ?
>
> Another approach (not tested by me, but maybe works) is using
> the JXTemplateGenerator. There is a tag that can be
> use to show/hide controls in the rendered page.
IIRC Sylvain extendet the showform function so that you can pass the
objects to the view layer. You could either use Antonio's suggestion or
you add a parameter to the widget styling.
My question: Is this the way we recommend or do we want to have widgets
an interface which can be used in order change presentation state?
WDOT?
--
Reinhard
Re: disabling widgets
Jeremy Quinn dijo:
> Hi All
>
> I have a booleanfield widget, that needs to be disabled under certain
> conditions.
>
> pseudo-code :
>
> if ( album.scenarios.size() > 0 ) {
>disable ( album.publishable );
> }
>
> ie. the album.publishable value needs to be in the form, but should not
> be alterable by the user.
>
> Is there a way of doing this in Cocoon Forms ?
Another approach (not tested by me, but maybe works) is using the
JXTemplateGenerator. There is a tag that can be use to show/hide
controls in the rendered page.
Best Regards,
Antonio Gallardo
RE: disabling widgets
Reinhard Poetz dijo: > From: Antonio Gallardo >> Based on some observation while no-tech oriented users filled >> HTML forms. It makes clear to me that they don't liked the >> round-trip to the server. It was confusing to him! It is >> clear a non-conventional interface. Also it waste time, no >> matter how fast the connection (including the server) are. >> The observation was related to calculated widgets. > > I made similar observations too. This means to me that we have to offer > a clear client-side Javascript interface in order to control the > widgets. This is why I think it would be fine to create a XUL interface reference for CForms. I am sure XUL can help more than HTML. I know the problem with XUL is that it currently only works in Mozilla and this is not a good idea in public Internet webapp. But in Intranets webapp we can have control of the clients too. ;-) I will do it a try. Best Regards, Antonio Gallardo.
RE: disabling widgets
From: Antonio Gallardo [mailto:[EMAIL PROTECTED]
> Reinhard Poetz dijo:
> > Sorry, I don't like this client-side approach.
> > We have to find something better because sometimes the
> 'presentation
> > state' of a widget can depend on the 'application state'.
> Flowscript
> > as controller should have access to both.
>
> Hi Reinhard:
>
> How manage a dynamic "show/hide a control" in a page without
> doing a round-trip to the server?
Maybe I haven't understood Jeremy's requirements correctly but I don't
think the widget should change because a widget changed client-side
(without server interaction).
> Based on some observation while no-tech oriented users filled
> HTML forms. It makes clear to me that they don't liked the
> round-trip to the server. It was confusing to him! It is
> clear a non-conventional interface. Also it waste time, no
> matter how fast the connection (including the server) are.
> The observation was related to calculated widgets.
I made similar observations too. This means to me that we have to offer
a clear client-side Javascript interface in order to control the
widgets.
+1 from me to give every widget a unique ID.
BTW, you suggested before
function toggleControl(id) {
var element = document.getElementById(id);
with (element.style) {
if (display == "none") {
display = ""
} else{
display = "none"
}
}
}
I think in this particular case you don't even need the id because pass
'this' to the toogleControl function which is a reference to the object.
function toggleControl(element) {
with (element.style) {
if (display == "none") {
display = ""
} else{
display = "none"
}
}
}
> I think this is a similar case, because the show/hide control
> is just a rendering page issue. Of course, you can add add
> additional parameters to reflect the current "application
> state" and let the page have the right behavior. If we
> suspect that it can be a security concerns, there is a gold rule:
>
> "Anything returned from the client must the checked again,
> when the control return to the Flow (serversided)."
Of course, never trust the client ;-)
> Best Regards,
>
> Antonio Gallardo.
>
> P.S: I like this kind of discussion, because I will learn more! :-)
--
Reinhard
Re: disabling widgets
Jeremy Quinn dijo:
if ( album.scenarios.size() > 0 ) {
disable ( album.publishable );
}
Is there a way of doing this in Cocoon Forms ?
>>>
I thought I don't understand this clear. Did you want to do this just when
the page is rendered?
Then look for , and soon. Here is the docs published
by Tim Larson:
http://wiki.cocoondev.org/Wiki.jsp?page=TimLarson
I think it would help you. The code is already on the CVS and AFAIK, it
was released on the 2.1.4
Best Regards,
Antonio Gallardo
P.S: Sorry, but sometimes I don't understand clear the mails :(
Best Regards,
Antonio Gallardo
RE: disabling widgets
Reinhard Poetz dijo: > Sorry, I don't like this client-side approach. > We have to find something better because sometimes the 'presentation > state' of a widget can depend on the 'application state'. Flowscript as > controller should have access to both. Hi Reinhard: How manage a dynamic "show/hide a control" in a page without doing a round-trip to the server? Based on some observation while no-tech oriented users filled HTML forms. It makes clear to me that they don't liked the round-trip to the server. It was confusing to him! It is clear a non-conventional interface. Also it waste time, no matter how fast the connection (including the server) are. The observation was related to calculated widgets. I think this is a similar case, because the show/hide control is just a rendering page issue. Of course, you can add add additional parameters to reflect the current "application state" and let the page have the right behavior. If we suspect that it can be a security concerns, there is a gold rule: "Anything returned from the client must the checked again, when the control return to the Flow (serversided)." Best Regards, Antonio Gallardo. P.S: I like this kind of discussion, because I will learn more! :-)
Re: disabling widgets
On 25 Feb 2004, at 11:32, Reinhard Poetz wrote:
From: Antonio Gallardo [mailto:[EMAIL PROTECTED]
Jeremy Quinn dijo:
I have a booleanfield widget, that needs to be disabled
under certain
conditions.
pseudo-code :
if ( album.scenarios.size() > 0 ) {
disable ( album.publishable );
}
ie. the album.publishable value needs to be in the form, but should
not be alterable by the user.
Is there a way of doing this in Cocoon Forms ?
Hi Jeremy:
In short, no. Also a roundtrip to the server to do this is
not the best idea. I think the problem is similar as when we
needed to make some "calculated widgets". We solved the
problem in this way:
1-call a JS function in the OnLoad event of your page to
initializate any state of the controlled widget. 2-Add a
onChange event on "album.scenarios" that will check for size
and turn on of off the "album.publishable" control. The JS
code can be quite similar to this code:
function toggleControl(id) {
var element = document.getElementById(id);
with (element.style) {
if (display == "none") {
display = ""
} else{
display = "none"
}
}
}
AFAIK, you will need to change the woody.xslt to allow the
usage of OnLoad event in the of your HTML page.
As a example in the template I wrote:
...
BTW, because using clientside JS is very easy when we have
id's on every widget. I suggested to include id's even when
rendering the , but seems like nobody want it and
proposal was forgotten. :-(
Hope this help.
Many thanks for your suggestions Antonio.
Sorry, I don't like this client-side approach.
We have to find something better because sometimes the 'presentation
state' of a widget can depend on the 'application state'. Flowscript as
controller should have access to both.
+1 a woody-model based approach is better IMHO.
When it comes to Validation, we have a simple expression language, no?
That can validate one widget, based on the value of another widget?
I wonder if we could somehow implement enabling/disabling of widgets
with a similar technique.
regards Jeremy
smime.p7s
Description: S/MIME cryptographic signature
RE: disabling widgets
From: Antonio Gallardo [mailto:[EMAIL PROTECTED]
> Jeremy Quinn dijo:
> > I have a booleanfield widget, that needs to be disabled
> under certain
> > conditions.
> >
> > pseudo-code :
> >
> > if ( album.scenarios.size() > 0 ) {
> > disable ( album.publishable );
> > }
> >
> > ie. the album.publishable value needs to be in the form, but should
> > not be alterable by the user.
> >
> > Is there a way of doing this in Cocoon Forms ?
>
> Hi Jeremy:
>
> In short, no. Also a roundtrip to the server to do this is
> not the best idea. I think the problem is similar as when we
> needed to make some "calculated widgets". We solved the
> problem in this way:
>
> 1-call a JS function in the OnLoad event of your page to
> initializate any state of the controlled widget. 2-Add a
> onChange event on "album.scenarios" that will check for size
> and turn on of off the "album.publishable" control. The JS
> code can be quite similar to this code:
>
> function toggleControl(id) {
> var element = document.getElementById(id);
> with (element.style) {
> if (display == "none") {
> display = ""
> } else{
> display = "none"
> }
> }
> }
>
> AFAIK, you will need to change the woody.xslt to allow the
> usage of OnLoad event in the of your HTML page.
>
> As a example in the template I wrote:
>
>...
>
>
>OnChange="calculateTheOtherWidget(this);"/>
>
>
> ...
>
>
> BTW, because using clientside JS is very easy when we have
> id's on every widget. I suggested to include id's even when
> rendering the , but seems like nobody want it and
> proposal was forgotten. :-(
>
> Hope this help.
Sorry, I don't like this client-side approach.
We have to find something better because sometimes the 'presentation
state' of a widget can depend on the 'application state'. Flowscript as
controller should have access to both.
--
Reinhard
Re: disabling widgets
Jeremy Quinn dijo:
> I have a booleanfield widget, that needs to be disabled under certain
> conditions.
>
> pseudo-code :
>
> if ( album.scenarios.size() > 0 ) {
>disable ( album.publishable );
> }
>
> ie. the album.publishable value needs to be in the form, but should not
> be alterable by the user.
>
> Is there a way of doing this in Cocoon Forms ?
Hi Jeremy:
In short, no. Also a roundtrip to the server to do this is not the best
idea. I think the problem is similar as when we needed to make some
"calculated widgets". We solved the problem in this way:
1-call a JS function in the OnLoad event of your page to initializate any
state of the controlled widget.
2-Add a onChange event on "album.scenarios" that will check for size and
turn on of off the "album.publishable" control. The JS code can be quite
similar to this code:
function toggleControl(id) {
var element = document.getElementById(id);
with (element.style) {
if (display == "none") {
display = ""
} else{
display = "none"
}
}
}
AFAIK, you will need to change the woody.xslt to allow the usage of OnLoad
event in the of your HTML page.
As a example in the template I wrote:
...
BTW, because using clientside JS is very easy when we have id's on every
widget. I suggested to include id's even when rendering the ,
but seems like nobody want it and proposal was forgotten. :-(
Hope this help.
Best Regards,
Antonio Gallardo
