[Cforms] "selectability" intrinsic to RepeaterRow? (was Re: [CForms binding] access to model data from repeater row widget)

[Mark Lundquist <ml...@wrinkledog.com>]

On Jun 22, 2005, at 2:17 AM, Sylvain Wallez wrote:

> Mark Lundquist wrote:
>> On Jun 20, 2005, at 11:42 PM, Sylvain Wallez wrote:
>> [8<----snip!----]
>>
>>>     And even more, repeater actions could have constraints on the
>>>     selection size, such as single-selection, multiple-selection,
>>>     leading these actions to be disabled if their associated
>>>     constraint isn't met.
>>
>> ...or a validation error. Like the classic "you must choose at least 
>> one" constraint.
>>
> Not sure this is a validation error. In the case of actions this 
> should be more a transient message (e.g. a popup).

D'oh, my bad... I missed that you are talking about repeater _actions_. 
  Gotta read slower...

Anyway, that is a good idea.  And be that as it may... I would also 
like automatic validation for the "must choose at least one" scenario, 
because I've had to code it by hand — gee, probably _twice_ now! :-).  
In my book, that calls for automation! :-)  Anyway, if selectedness 
were made intrinsic as you propose, then that would enable this 
validation.

Actually, I guess as "at least one" is the range [1..], we should 
support the more general 'range' validation criterion here.  Maybe we 
can generalize <fd:value-count> for this?

>  That isn't persisted across successive posts of a form. Now we may 
> consider that actions have a special way of handling validation errors 
> by clearing them at each readFromRequest() which is different from 
> other widget types.
>
>>>     And finally, we may be able to specify on repeater bindings if
>>>     they have to act on the whole repeater on just on the selection.
>>
>> Not sure what you mean, can you give an example?
>
> The idea is to specify in the binding if it should operate on the full 
> repeater or only on the selected rows. Something like:
> <fb:repeater use-selection="true">

Right :-)  But it does sound like it could lead to usability issues 
(error-prone form designs).  I'm having trouble thinking of where 
use-selection="true" in a binding would be actually useful...?

best regards,
—ml—

Re: [Cforms] "selectability" intrinsic to RepeaterRow? (was Re: [CForms binding] access to model data from repeater row widget)

[Sylvain Wallez <sy...@apache.org>]

Mark Lundquist wrote:

> On Jun 22, 2005, at 2:17 AM, Sylvain Wallez wrote:
>
>> Mark Lundquist wrote:
>>
>>> On Jun 20, 2005, at 11:42 PM, Sylvain Wallez wrote:
>>> [8<----snip!----]
>>>
>>>>     And even more, repeater actions could have constraints on the
>>>>     selection size, such as single-selection, multiple-selection,
>>>>     leading these actions to be disabled if their associated
>>>>     constraint isn't met.
>>>
>>>
>>> ...or a validation error. Like the classic "you must choose at least 
>>> one" constraint.
>>>
>> Not sure this is a validation error. In the case of actions this 
>> should be more a transient message (e.g. a popup).
>
>
> D'oh, my bad... I missed that you are talking about repeater 
> _actions_.  Gotta read slower...
>
> Anyway, that is a good idea.  And be that as it may... I would also 
> like automatic validation for the "must choose at least one" scenario, 
> because I've had to code it by hand — gee, probably _twice_ now! :-).  
> In my book, that calls for automation! :-)  Anyway, if selectedness 
> were made intrinsic as you propose, then that would enable this 
> validation.


Definitely.

> Actually, I guess as "at least one" is the range [1..], we should 
> support the more general 'range' validation criterion here.  Maybe we 
> can generalize <fd:value-count> for this?


Hmm... value-count is currently testing the number of values of the 
widget it is attached to, and in that case it would test the repeater 
attached to the action widget...

Also, an action's validators are more rules defining the availability of 
the action, and should therefore be evaluated earlier than validations, 
to provide better user feedback, as a disabled button is better than an 
enabled one that pops up a "you can't do that" when you click on it. On 
the other hand, this feedback should be computed on the client-side to 
ensure action's availability isntantly reflect the state of selected rows.

Hmm... need to think more about it...

>>  That isn't persisted across successive posts of a form. Now we may 
>> consider that actions have a special way of handling validation 
>> errors by clearing them at each readFromRequest() which is different 
>> from other widget types.
>>
>>>>     And finally, we may be able to specify on repeater bindings if
>>>>     they have to act on the whole repeater on just on the selection.
>>>
>>>
>>> Not sure what you mean, can you give an example?
>>
>>
>> The idea is to specify in the binding if it should operate on the 
>> full repeater or only on the selected rows. Something like:
>> <fb:repeater use-selection="true">
>
>
> Right :-)  But it does sound like it could lead to usability issues 
> (error-prone form designs).  I'm having trouble thinking of where 
> use-selection="true" in a binding would be actually useful...?


What about filling a shopping cart from a repeater showing a list of 
articles, keeping only the selected ones?

Sylvain

-- 
Sylvain Wallez                        Anyware Technologies
http://apache.org/~sylvain            http://anyware-tech.com
Apache Software Foundation Member     Research & Technology Director