You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Claudius Spellmann <cl...@juwimm.com> on 2004/09/22 12:00:59 UTC
CForms making widgets invisible
Hi,
I've created a patch to set a visibilitystatus for widgets. This means
that all widgets can be set visible or invisible on a form when a form
is created or using flowscript.
Here is an example for making a form invisible when defining the form:
/ <fd:field id="other">
<fd:label>Andere</fd:label>
<fd:datatype base="string"/>
<!-- make the form invisible to the user (This field is optional)-->
<fd:visible value="false"/>
</fd:field>/
And here an example to use it in flowscript (only implemented in V2 so
far)
/ var form = new Form("someForm.xml");
var widget = form.getWidget();
// make other visible if invisible
widget.other.visible = true;
// make other invisible if visible
widget.other.visible = false;
// get the current visibilitystatus for other
var visibilityStatus = widget.other.visible;/
I've used the latest dev version from the apache svn repository to
create this patch so currently it only works with the 2.2.0 dev version
of cocoon.
The appended patch file contains all the changes I've made.
greets
Claudius
By the way I've seen there are some references to my local filesystem
I hope these references are compatible/wont matter for applying the patch.
Re: Widget states: let's do it (was Re: CForms making widgets invisible)
Posted by Sylvain Wallez <sy...@apache.org>.
Claudius Spellmann wrote:
> Sylvain Wallez schrieb:
>
>> Claudius Spellmann wrote:
>>
>>> Sylvain Wallez schrieb:
>>
>>
>>
>>
>> <snip/>
>>
>>>> Mmmh... we could say that validation is not performed on
>>>> disabled/invisible widgets and their children. But this may cause
>>>> some forms to appear falsely valid, as non-enabled widgets may be
>>>> required and/or have validators that use values of other widgets.
>>>>
>>>> So I would better go the safer way, which is to validate *all*
>>>> widgets.
>>>>
>>>> As for wizards, we could have an additional method on the JS Form
>>>> object that, instead of handling the whole form at once, may handle
>>>> it's first-level children which may be widget groups for each page
>>>> of the wizard.
>>>>
>>>> Sylvain
>>>>
>>> Ok if a widget is set invisible it is not rendered by cocoon but
>>> that doesn't mean that the widget is not existing in the widget
>>> container so if a widget is required and not visible but still
>>> exists in the container does mean it could be validated ????
>>
>>
>>
>>
>> Yes.
>>
>>> What about following widget states: enabled (default) < disabled <
>>> hidden < invisible
>>> The difference between hidden and invisible would be that hidden is
>>> still rendered but with an hidden attribute in the declaration and
>>> would go through the validation process. Invisible on the other side
>>> could be taken of the form completly and while a widget is in an
>>> invisible state all validation would be switched off. This way every
>>> user could decide wether they want to use validation or not and the
>>> output still would look the same.
>>
>>
>>
>>
>> Interesting thoughts. But as we saw previously, "hidden" has an
>> implied meaning because of its use for <input type="hidden"> in HTML
>> and I'd like to avoid it.
>>
>> What you're describing here is a widget state that is even less
>> visible than invisible, since no validation occurs. What about a
>> "phantom" state, where the widget exists but isn't validated?
>>
>> BTW, overnight I finally felt that "enabled" being the negation of
>> "disabled" can lead to confusion as when we have to talk about a
>> widget that's not in "enable" state, the natural word that comes is
>> "disabled" which is only one of the particular possible states for a
>> non-enabled widget. So in the end, I think "active" is better than
>> "enabled".
>>
>> That would lead to:
>> active (default) < disabled < invisible < phantom
>>
>> Thoughts?
>>
>> Sylvain
>>
> Ok sounds good to me
>
> What would happen when an invisible field doesn't pass validation and
> the enduser of a running system doesn't know that he's made a mistake
> entering data.
> The point I'm trying to make is that informing endusers about
> validation errors could be a tricky issue becausae a user can't enter
> data into fields he cannot see and would be a burden for system
> developers because they have to test forms throughly to avoid confusion
Yes, that a problem we already have to face today if e.g. a required
widget is not present in the form template.
Some ideas about this problem?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Widget states: let's do it (was Re: CForms making widgets invisible)
Posted by Claudius Spellmann <cl...@juwimm.com>.
Sylvain Wallez schrieb:
> Claudius Spellmann wrote:
>
>> Sylvain Wallez schrieb:
>
>
>
> <snip/>
>
>>> Mmmh... we could say that validation is not performed on
>>> disabled/invisible widgets and their children. But this may cause
>>> some forms to appear falsely valid, as non-enabled widgets may be
>>> required and/or have validators that use values of other widgets.
>>>
>>> So I would better go the safer way, which is to validate *all* widgets.
>>>
>>> As for wizards, we could have an additional method on the JS Form
>>> object that, instead of handling the whole form at once, may handle
>>> it's first-level children which may be widget groups for each page
>>> of the wizard.
>>>
>>> Sylvain
>>>
>> Ok if a widget is set invisible it is not rendered by cocoon but that
>> doesn't mean that the widget is not existing in the widget container
>> so if a widget is required and not visible but still exists in the
>> container does mean it could be validated ????
>
>
>
> Yes.
>
>> What about following widget states: enabled (default) < disabled <
>> hidden < invisible
>> The difference between hidden and invisible would be that hidden is
>> still rendered but with an hidden attribute in the declaration and
>> would go through the validation process. Invisible on the other side
>> could be taken of the form completly and while a widget is in an
>> invisible state all validation would be switched off. This way every
>> user could decide wether they want to use validation or not and the
>> output still would look the same.
>
>
>
> Interesting thoughts. But as we saw previously, "hidden" has an
> implied meaning because of its use for <input type="hidden"> in HTML
> and I'd like to avoid it.
>
> What you're describing here is a widget state that is even less
> visible than invisible, since no validation occurs. What about a
> "phantom" state, where the widget exists but isn't validated?
>
> BTW, overnight I finally felt that "enabled" being the negation of
> "disabled" can lead to confusion as when we have to talk about a
> widget that's not in "enable" state, the natural word that comes is
> "disabled" which is only one of the particular possible states for a
> non-enabled widget. So in the end, I think "active" is better than
> "enabled".
>
> That would lead to:
> active (default) < disabled < invisible < phantom
>
> Thoughts?
>
> Sylvain
>
Ok sounds good to me
What would happen when an invisible field doesn't pass validation and
the enduser of a running system doesn't know that he's made a mistake
entering data.
The point I'm trying to make is that informing endusers about validation
errors could be a tricky issue becausae a user can't enter data into
fields he cannot see and would be a burden for system developers because
they have to test forms throughly to avoid confusion
Claudius.
Re: Widget states: let's do it (was Re: CForms making widgets invisible)
Posted by Sylvain Wallez <sy...@apache.org>.
Claudius Spellmann wrote:
> Sylvain Wallez schrieb:
<snip/>
>> Mmmh... we could say that validation is not performed on
>> disabled/invisible widgets and their children. But this may cause
>> some forms to appear falsely valid, as non-enabled widgets may be
>> required and/or have validators that use values of other widgets.
>>
>> So I would better go the safer way, which is to validate *all* widgets.
>>
>> As for wizards, we could have an additional method on the JS Form
>> object that, instead of handling the whole form at once, may handle
>> it's first-level children which may be widget groups for each page of
>> the wizard.
>>
>> Sylvain
>>
> Ok if a widget is set invisible it is not rendered by cocoon but that
> doesn't mean that the widget is not existing in the widget container
> so if a widget is required and not visible but still exists in the
> container does mean it could be validated ????
Yes.
> What about following widget states: enabled (default) < disabled <
> hidden < invisible
> The difference between hidden and invisible would be that hidden is
> still rendered but with an hidden attribute in the declaration and
> would go through the validation process. Invisible on the other side
> could be taken of the form completly and while a widget is in an
> invisible state all validation would be switched off. This way every
> user could decide wether they want to use validation or not and the
> output still would look the same.
Interesting thoughts. But as we saw previously, "hidden" has an implied
meaning because of its use for <input type="hidden"> in HTML and I'd
like to avoid it.
What you're describing here is a widget state that is even less visible
than invisible, since no validation occurs. What about a "phantom"
state, where the widget exists but isn't validated?
BTW, overnight I finally felt that "enabled" being the negation of
"disabled" can lead to confusion as when we have to talk about a widget
that's not in "enable" state, the natural word that comes is "disabled"
which is only one of the particular possible states for a non-enabled
widget. So in the end, I think "active" is better than "enabled".
That would lead to:
active (default) < disabled < invisible < phantom
Thoughts?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Widget states: let's do it (was Re: CForms making widgets invisible)
Posted by Claudius Spellmann <cl...@juwimm.com>.
Sylvain Wallez schrieb:
> Upayavira wrote:
>
>> Sylvain Wallez wrote:
>>
>>> Claudius Spellmann wrote:
>>>
>>>> Hi,
>>>>
>>>> I've created a patch to set a visibilitystatus for widgets. This
>>>> means that all widgets can be set visible or invisible on a form
>>>> when a form is created or using flowscript.
>>>
>>>
>>>
>>>
>>>
>>> This has already been discussed here: we need widget states.
>>> However, state isn't limited to visible/invisible. We also need
>>> states like active/inactive.
>>>
>>> AFAIR, the list of states we came up to was:
>>> - active : the current behaviour
>>> - disabled: the widget is displayed, but its value (or sub-widgets
>>> in the case of containers) isn't read from the request.
>>> - hidden: the widget isn't displayed, and of course it's value isn't
>>> read from the request.
>>>
>>> States should be inherited by child widgets, taking into account the
>>> following state priority:
>>> active < disabled < hidden.
>>>
>>> That means that if a repeater is hidden, its children will be hidden
>>> also even if their own state is active or disabled.
>>>
>>> We also need to be able to set an intial state in the form
>>> definition (default being "active"). I propose a common "state"
>>> attribute for this, available on all widget types, e.g.
>>> <fd:repeater id="foo" state="hidden">
>>> ...
>>> </fd:repeater>
>>>
>>> We've discussed this many times and it appears it is a real need
>>> now, so let's do it right now.
>>>
>>> Are we ok with this definition?
>>
>>
>>
>> How does this relate to validation? The reason I ask is that this
>> feels very close to support for wizards (unless I'm just being stupid).
>>
>> If we can 'group' a few widgets together, and enable or disable them,
>> we could then show part (a) of the form, then part (b), etc. Now, if
>> a field in this contect is 'disabled', a value will not be read from
>> the request, and no validation would be done on its value.
>>
>> Thoughts? Am I off beam?
>
>
>
> No, but you add another concern to the picture :-)
>
> Mmmh... we could say that validation is not performed on
> disabled/invisible widgets and their children. But this may cause some
> forms to appear falsely valid, as non-enabled widgets may be required
> and/or have validators that use values of other widgets.
>
> So I would better go the safer way, which is to validate *all* widgets.
>
> As for wizards, we could have an additional method on the JS Form
> object that, instead of handling the whole form at once, may handle
> it's first-level children which may be widget groups for each page of
> the wizard.
>
> Sylvain
>
Ok if a widget is set invisible it is not rendered by cocoon but that
doesn't mean that the widget is not existing in the widget container so
if a widget is required and not visible but still exists in the
container does mean it could be validated ????
What about following widget states: enabled (default) < disabled <
hidden < invisible
The difference between hidden and invisible would be that hidden is
still rendered but with an hidden attribute in the declaration and would
go through the validation process. Invisible on the other side could be
taken of the form completly and while a widget is in an invisible state
all validation would be switched off. This way every user could decide
wether they want to use validation or not and the output still would
look the same.
Just some ideas
Claudius
Re: Widget states: let's do it (was Re: CForms making widgets invisible)
Posted by Sylvain Wallez <sy...@apache.org>.
Upayavira wrote:
> Sylvain Wallez wrote:
>
>> Claudius Spellmann wrote:
>>
>>> Hi,
>>>
>>> I've created a patch to set a visibilitystatus for widgets. This
>>> means that all widgets can be set visible or invisible on a form
>>> when a form is created or using flowscript.
>>
>>
>>
>>
>> This has already been discussed here: we need widget states. However,
>> state isn't limited to visible/invisible. We also need states like
>> active/inactive.
>>
>> AFAIR, the list of states we came up to was:
>> - active : the current behaviour
>> - disabled: the widget is displayed, but its value (or sub-widgets in
>> the case of containers) isn't read from the request.
>> - hidden: the widget isn't displayed, and of course it's value isn't
>> read from the request.
>>
>> States should be inherited by child widgets, taking into account the
>> following state priority:
>> active < disabled < hidden.
>>
>> That means that if a repeater is hidden, its children will be hidden
>> also even if their own state is active or disabled.
>>
>> We also need to be able to set an intial state in the form definition
>> (default being "active"). I propose a common "state" attribute for
>> this, available on all widget types, e.g.
>> <fd:repeater id="foo" state="hidden">
>> ...
>> </fd:repeater>
>>
>> We've discussed this many times and it appears it is a real need now,
>> so let's do it right now.
>>
>> Are we ok with this definition?
>
>
> How does this relate to validation? The reason I ask is that this
> feels very close to support for wizards (unless I'm just being stupid).
>
> If we can 'group' a few widgets together, and enable or disable them,
> we could then show part (a) of the form, then part (b), etc. Now, if a
> field in this contect is 'disabled', a value will not be read from the
> request, and no validation would be done on its value.
>
> Thoughts? Am I off beam?
No, but you add another concern to the picture :-)
Mmmh... we could say that validation is not performed on
disabled/invisible widgets and their children. But this may cause some
forms to appear falsely valid, as non-enabled widgets may be required
and/or have validators that use values of other widgets.
So I would better go the safer way, which is to validate *all* widgets.
As for wizards, we could have an additional method on the JS Form object
that, instead of handling the whole form at once, may handle it's
first-level children which may be widget groups for each page of the wizard.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Widget states: let's do it (was Re: CForms making widgets invisible)
Posted by Upayavira <uv...@upaya.co.uk>.
Sylvain Wallez wrote:
> Claudius Spellmann wrote:
>
>> Hi,
>>
>> I've created a patch to set a visibilitystatus for widgets. This
>> means that all widgets can be set visible or invisible on a form when
>> a form is created or using flowscript.
>
>
>
> This has already been discussed here: we need widget states. However,
> state isn't limited to visible/invisible. We also need states like
> active/inactive.
>
> AFAIR, the list of states we came up to was:
> - active : the current behaviour
> - disabled: the widget is displayed, but its value (or sub-widgets in
> the case of containers) isn't read from the request.
> - hidden: the widget isn't displayed, and of course it's value isn't
> read from the request.
>
> States should be inherited by child widgets, taking into account the
> following state priority:
> active < disabled < hidden.
>
> That means that if a repeater is hidden, its children will be hidden
> also even if their own state is active or disabled.
>
> We also need to be able to set an intial state in the form definition
> (default being "active"). I propose a common "state" attribute for
> this, available on all widget types, e.g.
> <fd:repeater id="foo" state="hidden">
> ...
> </fd:repeater>
>
> We've discussed this many times and it appears it is a real need now,
> so let's do it right now.
>
> Are we ok with this definition?
How does this relate to validation? The reason I ask is that this feels
very close to support for wizards (unless I'm just being stupid).
If we can 'group' a few widgets together, and enable or disable them, we
could then show part (a) of the form, then part (b), etc. Now, if a
field in this contect is 'disabled', a value will not be read from the
request, and no validation would be done on its value.
Thoughts? Am I off beam?
Regards, Upayavira
Re: Widget states: let's do it (was Re: CForms making widgets invisible)
Posted by Sylvain Wallez <sy...@apache.org>.
Claudius Spellmann wrote:
> Ok just two more questions:
>
> 1) The disabled state: Is it enough to just grey out disabled widgets
> and return any previously selected values or schould the widget-value
> be null when a widget is disabled.
The disabled state is only from the user point of view: the widget of
course holds its value.
> 2) Should forms also have states so that a whole form can be disabled
> or hidden.
Being a container, the form will also have a state, which will be
inherited by its children with the priority rules I proposed. Using
this, you'll be able to disable a whole form at once.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Widget states: let's do it (was Re: CForms making widgets invisible)
Posted by Claudius Spellmann <cl...@juwimm.com>.
Ok just two more questions:
1) The disabled state: Is it enough to just grey out disabled widgets
and return any previously selected values or schould the widget-value be
null when a widget is disabled.
2) Should forms also have states so that a whole form can be disabled or
hidden.
greets
Claudius
Sylvain Wallez schrieb:
> Claudius Spellmann wrote:
>
>> Hi,
>>
>> I've created a patch to set a visibilitystatus for widgets. This
>> means that all widgets can be set visible or invisible on a form when
>> a form is created or using flowscript.
>
>
>
> This has already been discussed here: we need widget states. However,
> state isn't limited to visible/invisible. We also need states like
> active/inactive.
>
> AFAIR, the list of states we came up to was:
> - active : the current behaviour
> - disabled: the widget is displayed, but its value (or sub-widgets in
> the case of containers) isn't read from the request.
> - hidden: the widget isn't displayed, and of course it's value isn't
> read from the request.
>
> States should be inherited by child widgets, taking into account the
> following state priority:
> active < disabled < hidden.
>
> That means that if a repeater is hidden, its children will be hidden
> also even if their own state is active or disabled.
>
> We also need to be able to set an intial state in the form definition
> (default being "active"). I propose a common "state" attribute for
> this, available on all widget types, e.g.
> <fd:repeater id="foo" state="hidden">
> ...
> </fd:repeater>
>
> We've discussed this many times and it appears it is a real need now,
> so let's do it right now.
>
> Are we ok with this definition?
>
> Sylvain
>
Re: Widget states: let's do it (was Re: CForms making widgets invisible)
Posted by Sylvain Wallez <sy...@apache.org>.
Vadim Gritsenko wrote:
> Sylvain Wallez wrote:
>
>> Vadim Gritsenko wrote:
>>
>>> Sylvain Wallez wrote:
>>>
>>>> And now, with "enabled"/"disabled"/"invisible"?
>>>
>>>
>>>
>>> I guess I'm Ok with that; can you also comment how it relates to:
>>> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108981424626685
>>>
>>>
>>> Your proposal seems to differ a bit by mixing presentation and
>>> input/output concern - I guess there is a reason for this too :)
>>
>>
>>
>> My proposal is only about what data comes in a out from the form
>> model. The state certainly impacts how it is displayed, but this can
>> be further refined in the view. For example Tim's "inline" and
>> "disabled" proposal are two possible stylings of a disabled widget,
>> in the same manner than an enabled widget that can have the "hidden"
>> styling.
>
>
> So it is almost as it was described in mentioned email:
>
>> Via the model (secure, does not rely on well-behaved clients)
>> Read/write - Like a normal widget
>> Readonly - Like an output widget.
>> Writeonly - For sensitive input (e.g. passwords not echoed to the
>> client.)
>> Neither - For server-side data (e.g. to still allow use of the other
>> benefits of cforms widgets, such as validation,
>> value-changed-events,
>> and the ability to load and save via bindings.)
>
>
> With the exception of Writeonly.
Exactly. As as stated previously, wite only seems to me a very specific
case that should be handled by a special fd:passwordfield widget, just
like we have fd:booleanfield.
> In this case, I'm +1, as long as styling concern is kept separate :)
Kewl :-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Widget states: let's do it (was Re: CForms making widgets invisible)
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Sylvain Wallez wrote:
> Vadim Gritsenko wrote:
>
>> Sylvain Wallez wrote:
>>
>>> And now, with "enabled"/"disabled"/"invisible"?
>>
>>
>> I guess I'm Ok with that; can you also comment how it relates to:
>> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108981424626685
>>
>>
>> Your proposal seems to differ a bit by mixing presentation and
>> input/output concern - I guess there is a reason for this too :)
>
>
> My proposal is only about what data comes in a out from the form model.
> The state certainly impacts how it is displayed, but this can be further
> refined in the view. For example Tim's "inline" and "disabled" proposal
> are two possible stylings of a disabled widget, in the same manner than
> an enabled widget that can have the "hidden" styling.
So it is almost as it was described in mentioned email:
> Via the model (secure, does not rely on well-behaved clients)
> Read/write - Like a normal widget
> Readonly - Like an output widget.
> Writeonly - For sensitive input (e.g. passwords not echoed to the client.)
> Neither - For server-side data (e.g. to still allow use of the other
> benefits of cforms widgets, such as validation, value-changed-events,
> and the ability to load and save via bindings.)
With the exception of Writeonly. In this case, I'm +1, as long as
styling concern is kept separate :)
Vadim
Re: Widget states: let's do it (was Re: CForms making widgets invisible)
Posted by Sylvain Wallez <sy...@apache.org>.
Vadim Gritsenko wrote:
> Sylvain Wallez wrote:
>
>> And now, with "enabled"/"disabled"/"invisible"?
>
>
> I guess I'm Ok with that; can you also comment how it relates to:
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108981424626685
>
>
> Your proposal seems to differ a bit by mixing presentation and
> input/output concern - I guess there is a reason for this too :)
My proposal is only about what data comes in a out from the form model.
The state certainly impacts how it is displayed, but this can be further
refined in the view. For example Tim's "inline" and "disabled" proposal
are two possible stylings of a disabled widget, in the same manner than
an enabled widget that can have the "hidden" styling.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Widget states: let's do it (was Re: CForms making widgets invisible)
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Sylvain Wallez wrote:
> And now, with "enabled"/"disabled"/"invisible"?
I guess I'm Ok with that; can you also comment how it relates to:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108981424626685
Your proposal seems to differ a bit by mixing presentation and
input/output concern - I guess there is a reason for this too :)
Vadim
Re: Widget states: let's do it (was Re: CForms making widgets invisible)
Posted by Sylvain Wallez <sy...@apache.org>.
Vadim Gritsenko wrote:
> Sylvain Wallez wrote:
>
>> Claudius Spellmann wrote:
>>
>>> I've created a patch to set a visibilitystatus for widgets. This
>>> means that all widgets can be set visible or invisible on a form
>>> when a form is created or using flowscript.
>>
>>
>>
>> This has already been discussed here: we need widget states. However,
>> state isn't limited to visible/invisible. We also need states like
>> active/inactive.
>>
>> AFAIR, the list of states we came up to was:
>> - active : the current behaviour
>> - disabled: the widget is displayed, but its value (or sub-widgets in
>> the case of containers) isn't read from the request.
>> - hidden: the widget isn't displayed, and of course it's value isn't
>> read from the request.
>
>
> So, we will have two different types of hidden? One is normal html
> type="hidden", which *reads* from request, and another is form's
> hidden, which does not?
They address different concerns: the <input type="hidden"> is a styling
concern, as the value has to be read from the request by the widget,
whereas the hidden state is an application concern which forbids access
to the widget by the client.
Maybe "invisible" as proposed by Claudius is better, as you can find
something that's "hidden" by searching around (i.e. looking at the page
source) whereas you can't find an invisible thing.
This "invisible" state led me to look back to AWT Component which has
setEnabled(boolean) and setVisible(boolean). IMO we should have only one
tri-state property because "invisible" is an increased constraint on the
enable status.
So finally, my proposal is "enabled" (default), "disabled", "invisible".
We also have the case of password fields [1] that should read a value
but not output it, but IMO this is a very special case that should be
handled by a special widget class.
<snip/>
>> Are we ok with this definition?
>
>
> Mostly.
And now, with "enabled"/"disabled"/"invisible"?
Sylvain
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108305466005202&w=2
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Widget states: let's do it (was Re: CForms making widgets invisible)
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Sylvain Wallez wrote:
> Claudius Spellmann wrote:
>
>> I've created a patch to set a visibilitystatus for widgets. This means
>> that all widgets can be set visible or invisible on a form when a form
>> is created or using flowscript.
>
>
> This has already been discussed here: we need widget states. However,
> state isn't limited to visible/invisible. We also need states like
> active/inactive.
>
> AFAIR, the list of states we came up to was:
> - active : the current behaviour
> - disabled: the widget is displayed, but its value (or sub-widgets in
> the case of containers) isn't read from the request.
> - hidden: the widget isn't displayed, and of course it's value isn't
> read from the request.
So, we will have two different types of hidden? One is normal html
type="hidden", which *reads* from request, and another is form's hidden,
which does not?
> States should be inherited by child widgets, taking into account the
> following state priority:
> active < disabled < hidden.
>
> That means that if a repeater is hidden, its children will be hidden
> also even if their own state is active or disabled.
>
> We also need to be able to set an intial state in the form definition
> (default being "active"). I propose a common "state" attribute for this,
> available on all widget types, e.g.
> <fd:repeater id="foo" state="hidden">
> ...
> </fd:repeater>
>
> We've discussed this many times and it appears it is a real need now, so
> let's do it right now.
>
> Are we ok with this definition?
Mostly.
Vadim
Widget states: let's do it (was Re: CForms making widgets invisible)
Posted by Sylvain Wallez <sy...@apache.org>.
Claudius Spellmann wrote:
> Hi,
>
> I've created a patch to set a visibilitystatus for widgets. This means
> that all widgets can be set visible or invisible on a form when a form
> is created or using flowscript.
This has already been discussed here: we need widget states. However,
state isn't limited to visible/invisible. We also need states like
active/inactive.
AFAIR, the list of states we came up to was:
- active : the current behaviour
- disabled: the widget is displayed, but its value (or sub-widgets in
the case of containers) isn't read from the request.
- hidden: the widget isn't displayed, and of course it's value isn't
read from the request.
States should be inherited by child widgets, taking into account the
following state priority:
active < disabled < hidden.
That means that if a repeater is hidden, its children will be hidden
also even if their own state is active or disabled.
We also need to be able to set an intial state in the form definition
(default being "active"). I propose a common "state" attribute for this,
available on all widget types, e.g.
<fd:repeater id="foo" state="hidden">
...
</fd:repeater>
We've discussed this many times and it appears it is a real need now, so
let's do it right now.
Are we ok with this definition?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }