Sylvain Wallez dijo:
> Antonio Gallardo wrote:
>
>>Hunsberger, Peter dijo:
>>
>>
>>>Sylvain Wallez <[EMAIL PROTECTED]> writes:
>>>
>>>
Yes, that a problem we already have to face today if e.g. a required
widget is not present in the form template.
>>
>>I think this is an applicati
Sylvain Wallez <[EMAIL PROTECTED]> writes:
>
> Hunsberger, Peter wrote:
>
> >Sylvain Wallez <[EMAIL PROTECTED]> asks:
> >
> >discussion on hidden etc.
> >
> >
> >>>I also think we can find a better names:
> >>>
> >>>formInclusion --> show, render, presentation, view, [fill a
> >>>
> >>>
Hunsberger, Peter wrote:
Sylvain Wallez <[EMAIL PROTECTED]> asks:
discussion on hidden etc.
I also think we can find a better names:
formInclusion --> show, render, presentation, view, [fill a
new name]
notIncluded --> Excluded validation --> validate
Ok, maybe the "phantom
Sylvain Wallez <[EMAIL PROTECTED]> asks:
discussion on hidden etc.
>
> >
> >I also think we can find a better names:
> >
> >formInclusion --> show, render, presentation, view, [fill a
> new name]
> >notIncluded --> Excluded validation --> validate
> >
> >
>
> Ok, maybe the "phantom" state i
Sylvain Wallez schrieb:
Antonio Gallardo wrote:
Hunsberger, Peter dijo:
Sylvain Wallez <[EMAIL PROTECTED]> writes:
Yes, that a problem we already have to face today if e.g. a required
widget is not present in the form template.
I think this is an application bug an we cannot take care
Antonio Gallardo wrote:
Hunsberger, Peter dijo:
Sylvain Wallez <[EMAIL PROTECTED]> writes:
Yes, that a problem we already have to face today if e.g. a required
widget is not present in the form template.
I think this is an application bug an we cannot take care of that in the
definit
Hunsberger, Peter wrote:
Vadim Gritsenko <[EMAIL PROTECTED]> writes:
Hunsberger, Peter wrote:
Vadim Gritsenko <[EMAIL PROTECTED]> writes:
Phones, credit card numbers, SSN, EIN, ITIN, etc, all can
be valid in parts but not valid as a whole.
For most of these cases you should probably use a single f
Hunsberger, Peter dijo:
> Sylvain Wallez <[EMAIL PROTECTED]> writes:
>> Yes, that a problem we already have to face today if e.g. a required
>> widget is not present in the form template.
I think this is an application bug an we cannot take care of that in the
definition. ;-) See below
>> Som
Vadim Gritsenko <[EMAIL PROTECTED]> writes:
>
> Hunsberger, Peter wrote:
>
> > Vadim Gritsenko <[EMAIL PROTECTED]> writes:
> >
> >>Phones, credit card numbers, SSN, EIN, ITIN, etc, all can
> be valid in
> >>parts but not valid as a whole.
> >
> >
> > For most of these cases you should probab
Hunsberger, Peter wrote:
Vadim Gritsenko <[EMAIL PROTECTED]> writes:
Phones, credit card numbers, SSN, EIN, ITIN, etc, all can be valid in
parts but not valid as a whole.
For most of these cases you should probably use a single field for data
entry.
You'd do one way, and other guy would do anothe
Vadim Gritsenko <[EMAIL PROTECTED]> writes:
>
> Hunsberger, Peter wrote:
>
> > Vadim Gritsenko <[EMAIL PROTECTED]> writes:
> >
> >>Hunsberger, Peter wrote:
> >>
> >>>why would you ever do validation on a field that the user cannot
> >>>change?
> >>
> >>There is an example. That's exactly how Ag
Hunsberger, Peter wrote:
Vadim Gritsenko <[EMAIL PROTECTED]> writes:
Hunsberger, Peter wrote:
why would you ever do validation on a field that the user cannot
change?
There is an example. That's exactly how AggregateWidget works. It
consists out of several visible widgets and one invisible (or
v
Vadim Gritsenko <[EMAIL PROTECTED]> writes:
>
> Hunsberger, Peter wrote:
>
> > why would you ever do validation on a field that the user cannot
> > change?
>
> There is an example. That's exactly how AggregateWidget works. It
> consists out of several visible widgets and one invisible (or
> v
Hunsberger, Peter wrote:
why would you ever do validation on a field that the user cannot
change?
There is an example. That's exactly how AggregateWidget works. It
consists out of several visible widgets and one invisible (or vice versa
- depending on direction). Invisible one gets value by aggre
Sylvain Wallez <[EMAIL PROTECTED]> writes:
discussion about widgets
> >> Interesting thoughts. But as we saw previously, "hidden" has an
> >> implied meaning because of its use for type="hidden"> in HTML
> >> and I'd like to avoid it.
> >>
> >> What you're describing here is a widget state that
Claudius Spellmann wrote:
Sylvain Wallez schrieb:
Claudius Spellmann wrote:
Sylvain Wallez schrieb:
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
requ
Sylvain Wallez schrieb:
Claudius Spellmann wrote:
Sylvain Wallez schrieb:
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
Claudius Spellmann wrote:
Sylvain Wallez schrieb:
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 othe
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 discus
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 diff
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 pres
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/ou
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 t
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
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 widge
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,
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,
sta
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
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
Cla
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 t
30 matches
Mail list logo
