You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Mark Lundquist <ml...@wrinkledog.com> on 2004/03/11 21:18:29 UTC

[cforms] Radio buttons across repeater

Hi,

I would like to have a repeater in which each row contains a single 
radio button, and where this set of radio buttons constitutes a group 
in the form, (i.e. have the same name).

Is there a way to do that in Cocoon Forms?

thx,
Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: [cforms] Radio buttons across repeater

Posted by Joerg Heinicke <jo...@gmx.de>.
On 07.04.2004 14:08, Marc Portier wrote:

>>> with it you wouldn't even need to declare it in your form-definition 
>>> since it really only has a purpose for the binding, and actually 
>>> never really is a true/valid widget, or is it?
>>
>> Not necessarily. I have two cases. One overview list of persons where 
>> an action
>> leads to a detail view. Here I need the ID in the flow/form model. And 
>> another
>> list view (the addresses, as part of person's detail view) where I do 
>> not need
>> to link, the addresses are completely edited in the list view. For the 
>> latter I
>> wanted to remove @unique-row-id/@unique-row-path, but that's not 
>> optional. So I
>> need a widget which is bound to the ID.
> 
> got it, but there is nothing that prevents it:
> 
> I don't think the row-idenity approach prevents you from declaring an 
> aditional id-widget in your definition file when you do need it.

Of course. It was only to show that there are some case where it is a 
widget in contrary to your sentence above.

> the image as it is starting to clear out in my head:
> - repeater has now alreday a list of rows
> - it could also maintain a hashmap where those rows with identity would 
> be hooked up (identity is set programmatically e.g. under control of the 
> binding)
> - rows added by front-end interaction would be identity-less and stacked 
> up in a set of unIdentifiedRows under the repeater
> 
> all of this doesn't mean that there could not be one of the widgets 
> inside the row holding an 'id' value (even user updateable)
> 
> making sense?

Absolutely.

> -marc=
> PS: this would completely set asside the IdentityBinding interface we 
> discussed earlier, I do hope you are glad you didn't spend your valuable 
> time on that :-)

Thanks again ;-)

Joerg

Re: [cforms] Radio buttons across repeater

Posted by Marc Portier <mp...@outerthought.org>.

Joerg Heinicke wrote:

> Marc Portier <mpo <at> outerthought.org> writes:
> 
> 
>>>>In light of the above we could even consider sending 
>>>>repeaterID.radioID=row-identity (which would require to 
>>>>serialize-to-string somehow this identity?)
> 
> 
> <snip what="separate backend IDs from frontend IDs"/>
> 
>>+1
>>
>>I'm still running around the hot soup of repeater-binding (in my head)
>>and your scenario (which I think is quite widespread) of the wd:output 
>>that never gets styled is for me an additional reason for having an 
>>intrinsic Identity property on each Reater.Row
>>
>>with it you wouldn't even need to declare it in your form-definition 
>>since it really only has a purpose for the binding, and actually never 
>>really is a true/valid widget, or is it?
> 
> 
> Not necessarily. I have two cases. One overview list of persons where an action
> leads to a detail view. Here I need the ID in the flow/form model. And another
> list view (the addresses, as part of person's detail view) where I do not need
> to link, the addresses are completely edited in the list view. For the latter I
> wanted to remove @unique-row-id/@unique-row-path, but that's not optional. So I
> need a widget which is bound to the ID.
> 

got it, but there is nothing that prevents it:

I don't think the row-idenity approach prevents you from declaring an 
aditional id-widget in your definition file when you do need it.

the image as it is starting to clear out in my head:
- repeater has now alreday a list of rows
- it could also maintain a hashmap where those rows with identity would 
be hooked up (identity is set programmatically e.g. under control of the 
binding)
- rows added by front-end interaction would be identity-less and stacked 
up in a set of unIdentifiedRows under the repeater

all of this doesn't mean that there could not be one of the widgets 
inside the row holding an 'id' value (even user updateable)

making sense?
-marc=
PS: this would completely set asside the IdentityBinding interface we 
discussed earlier, I do hope you are glad you didn't spend your valuable 
time on that :-)
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                http://blogs.cocoondev.org/mpo/
mpo@outerthought.org                              mpo@apache.org

Re: [cforms] Radio buttons across repeater

Posted by Joerg Heinicke <jo...@gmx.de>.
Marc Portier <mpo <at> outerthought.org> writes:

> >> In light of the above we could even consider sending 
> >> repeaterID.radioID=row-identity (which would require to 
> >> serialize-to-string somehow this identity?)

<snip what="separate backend IDs from frontend IDs"/>

> +1
> 
> I'm still running around the hot soup of repeater-binding (in my head)
> and your scenario (which I think is quite widespread) of the wd:output 
> that never gets styled is for me an additional reason for having an 
> intrinsic Identity property on each Reater.Row
> 
> with it you wouldn't even need to declare it in your form-definition 
> since it really only has a purpose for the binding, and actually never 
> really is a true/valid widget, or is it?

Not necessarily. I have two cases. One overview list of persons where an action
leads to a detail view. Here I need the ID in the flow/form model. And another
list view (the addresses, as part of person's detail view) where I do not need
to link, the addresses are completely edited in the list view. For the latter I
wanted to remove @unique-row-id/@unique-row-path, but that's not optional. So I
need a widget which is bound to the ID.

Joerg


Re: [cforms] Radio buttons across repeater

Posted by Marc Portier <mp...@outerthought.org>.

Joerg Heinicke wrote:
> On 06.04.2004 09:20, Marc Portier wrote:
> 
>> Joerg,
>>
>> I realize that 'resting my case' is not enough...
>>
>> some ideas:
>> this sounds like the operation 'selecting a row' should be an 
>> intrinsic feature of the repeater-widget
> 
> 
> Yes, sounds reasonable.
> 
>> In light of the above we could even consider sending 
>> repeaterID.radioID=row-identity (which would require to 
>> serialize-to-string somehow this identity?)
> 
> 
> This not IMO ;-) I completely separate backend IDs from row IDs as the 
> former ones might often be database IDs (general security concern). So 
> my binding ATM often has a @unique-row-id="id" (still 2.1.4), but ID is 
> only a wd:output in the definition and is not referred in the template. 
> At least for the moment I have no use case where the mapping from row ID 
> to backend ID does not match my requirements and so I'm hiding the 
> backend IDs from the user.
> 

+1

I'm still running around the hot soup of repeater-binding (in my head)
and your scenario (which I think is quite widespread) of the wd:output 
that never gets styled is for me an additional reason for having an 
intrinsic Identity property on each Reater.Row

with it you wouldn't even need to declare it in your form-definition 
since it really only has a purpose for the binding, and actually never 
really is a true/valid widget, or is it?

regards,
-marc=
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                http://blogs.cocoondev.org/mpo/
mpo@outerthought.org                              mpo@apache.org

Re: [cforms] Radio buttons across repeater

Posted by Joerg Heinicke <jo...@gmx.de>.
On 06.04.2004 09:20, Marc Portier wrote:

> Joerg,
> 
> I realize that 'resting my case' is not enough...
> 
> some ideas:
> this sounds like the operation 'selecting a row' should be an intrinsic 
> feature of the repeater-widget

Yes, sounds reasonable.

> In light of the above we could even consider sending 
> repeaterID.radioID=row-identity (which would require to 
> serialize-to-string somehow this identity?)

This not IMO ;-) I completely separate backend IDs from row IDs as the 
former ones might often be database IDs (general security concern). So 
my binding ATM often has a @unique-row-id="id" (still 2.1.4), but ID is 
only a wd:output in the definition and is not referred in the template. 
At least for the moment I have no use case where the mapping from row ID 
to backend ID does not match my requirements and so I'm hiding the 
backend IDs from the user.

Joerg

Re: [cforms] Radio buttons across repeater

Posted by Bruno Dumon <br...@outerthought.org>.
On Tue, 2004-04-06 at 09:20, Marc Portier wrote:
> Joerg,
> 
> I realize that 'resting my case' is not enough...
> 
> some ideas:
> this sounds like the operation 'selecting a row' should be an intrinsic 
> feature of the repeater-widget

exactly my idea when I saw the message on users, +1

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org                          bruno@apache.org


Re: [cforms] Radio buttons across repeater

Posted by Marc Portier <mp...@outerthought.org>.
Joerg,

I realize that 'resting my case' is not enough...

some ideas:
this sounds like the operation 'selecting a row' should be an intrinsic 
feature of the repeater-widget

to some extend we already have a means of selecting (multiple) rows by 
putting a checkbox in every row which results in 
repeaterID.rowID.checkBoxID=true (e.g. contacts.0.select=true)

in this case we would however need some repeaterID.radioID=rowID

this shows that this selector-variable is not a child of the row, but of 
the repeater itself, furthermore I don't think it is a unique property 
like repeaterID.size since people might want to have more then one 
selection made, no?

maybe this calls for a nested <fd:selectors> in the repeater definition?

<fd:repeater id="contacts" >
   <fd:selectors>..</fd:selectors>
   <fd:widgets>...</fd:widgets>
</fd:repeater>

wdyt?



Related (but different):
I'm still in preparation mode of the update on the repeater-binding
I've started to develop an idea where 'identity' would be a property of 
the row (which it currently doesn't have) and let the identity binding 
exactly bind its value into that 'space' (still have to crack up some 
nice way to model that, ATM I think a wrapper around a simple arraylist 
would do, having an equals() that checks on every element in the list)

In light of the above we could even consider sending 
repeaterID.radioID=row-identity (which would require to 
serialize-to-string somehow this identity?)


regards,
-marc=

Marc Portier wrote:

> 
> Joerg Heinicke wrote:
> 
>> On 12.03.2004 09:02, Marc Portier wrote:
>>
>>>>> I would like to have a repeater in which each row contains a single 
>>>>> radio button, and where this set of radio buttons constitutes a 
>>>>> group in the form, (i.e. have the same name).
>>>>>
>>>>> Is there a way to do that in Cocoon Forms?
>>>
>>>
>>>
>>> hm, I'm afraid this is not why repeaters are there,
>>> this sounds more like a case of selection-list with radio styling...
>>
>>
>>
>> I thought of the same thing (radio buttons across repeater) when 
>> thinking about my use case:
>> - a person with multiple addresses (=> repeater)
>> - one of these addresses is the main address, that would be selected 
>> for sending letters (=> radio buttons, one in each row)
>>
>> Of course I can do this via an additional widget (selection list), but 
>> I don't find this very intuitive.
>>
>> WDYT?
>>
> 
> I rest my case... thx for making me see
> 
> -marc=

-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                http://blogs.cocoondev.org/mpo/
mpo@outerthought.org                              mpo@apache.org

Re: [cforms] Radio buttons across repeater

Posted by Marc Portier <mp...@outerthought.org>.

Joerg Heinicke wrote:
> On 12.03.2004 09:02, Marc Portier wrote:
> 
>>>> I would like to have a repeater in which each row contains a single 
>>>> radio button, and where this set of radio buttons constitutes a 
>>>> group in the form, (i.e. have the same name).
>>>>
>>>> Is there a way to do that in Cocoon Forms?
>>
>>
>> hm, I'm afraid this is not why repeaters are there,
>> this sounds more like a case of selection-list with radio styling...
> 
> 
> I thought of the same thing (radio buttons across repeater) when 
> thinking about my use case:
> - a person with multiple addresses (=> repeater)
> - one of these addresses is the main address, that would be selected for 
> sending letters (=> radio buttons, one in each row)
> 
> Of course I can do this via an additional widget (selection list), but I 
> don't find this very intuitive.
> 
> WDYT?
> 

I rest my case... thx for making me see

-marc=
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                http://blogs.cocoondev.org/mpo/
mpo@outerthought.org                              mpo@apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: [cforms] Radio buttons across repeater

Posted by Joerg Heinicke <jo...@gmx.de>.
On 12.03.2004 09:02, Marc Portier wrote:

>>> I would like to have a repeater in which each row contains a single 
>>> radio button, and where this set of radio buttons constitutes a group 
>>> in the form, (i.e. have the same name).
>>>
>>> Is there a way to do that in Cocoon Forms?
> 
> hm, I'm afraid this is not why repeaters are there,
> this sounds more like a case of selection-list with radio styling...

I thought of the same thing (radio buttons across repeater) when 
thinking about my use case:
- a person with multiple addresses (=> repeater)
- one of these addresses is the main address, that would be selected for 
sending letters (=> radio buttons, one in each row)

Of course I can do this via an additional widget (selection list), but I 
don't find this very intuitive.

WDYT?

Joerg


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: [cforms] Radio buttons across repeater

Posted by Marc Portier <mp...@outerthought.org>.

Mark Lundquist wrote:

> 
> On Mar 11, 2004, at 12:18 PM, Mark Lundquist wrote:
> 
>> Hi,
>>
>> I would like to have a repeater in which each row contains a single 
>> radio button, and where this set of radio buttons constitutes a group 
>> in the form, (i.e. have the same name).
>>
>> Is there a way to do that in Cocoon Forms?
> 
> 
> OK, I think the way to do it would be to interpose a stylesheet between 
> the Woody template transformer and the woody stylesheet, so that I could 
> get the first crack at the widget instance elements.
> 
> Anyway, I'm not gonna go with that style of form, for unrelated reasons.
> 

hm, I'm afraid this is not why repeaters are there,
this sounds more like a case of selection-list with radio styling...

see the samples form1.xml and form1_template.xml for the field 'cowheight'

- in the model you define it as a field with a nested selection-list
- in the template you just add styling list-type="radio"

explanation: if you talk about a repeater, then you think about some 
kind of a 1-M relation between the form and the various widgets inside 
the repeater.  In this case you just want ONE value, so you only want 
one widget. The fact that the selection-list is presented as a set of 
radio-buttons is a styling only issue. (at least according to the 
filosophy of cforms)

HTH

-marc=

> ~ Mark
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
> 

-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                http://blogs.cocoondev.org/mpo/
mpo@outerthought.org                              mpo@apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: [cforms] Radio buttons across repeater

Posted by Mark Lundquist <ml...@wrinkledog.com>.
On Mar 11, 2004, at 12:18 PM, Mark Lundquist wrote:

> Hi,
>
> I would like to have a repeater in which each row contains a single 
> radio button, and where this set of radio buttons constitutes a group 
> in the form, (i.e. have the same name).
>
> Is there a way to do that in Cocoon Forms?

OK, I think the way to do it would be to interpose a stylesheet between 
the Woody template transformer and the woody stylesheet, so that I 
could get the first crack at the widget instance elements.

Anyway, I'm not gonna go with that style of form, for unrelated reasons.

~ Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org