[Seaside-dev] Re: [Seaside Commits] Seaside 3.0: Seaside-Tests-Functional-obi.101.mcz

[Gerhard Obermann]

What about making a new class for
e.g. called WARadioGroupTag.
In that case i would change back the code for WARadioGroup.

The code would be similar to the select lists:

 html radioGroupList
               list: self elements;
               selected: self selected;
               callback: [ :value | selected := value ]

BTW how to get the group from button. There is no direct reference or am i
missing something.

Gerhard

On Wed, Dec 30, 2009 at 9:42 PM, Julian Fitzell <jfitzell at gmail.com> wrote:

> On Wed, Dec 30, 2009 at 10:01 AM, Lukas Renggli <renggli at gmail.com> wrote:
> > I think this is a good improvement, but we have to be careful.
> > Behavior seems to be a bit distributed at the moment, for example the
> > callback is on the group but the selection is still on the individual
> > options?
>
> I had the same response to the selection being on the radio group. I
> also don't like having to call #valueFor: on the radio group when
> passing in the value; since the button knows the group, you should
> just be able to pass in the object you want associated with it and
> have the radio button deal with getting a unique key from the group. I
> also then wondered whether it wouldn't be nicer to get the button from
> the group. So all put together it might look something like:
>
> html radioGroup
>  callback: [ :value | self setFoo: value ];
>  selection: self getFoo;
>  with: [ :group |
>    (1 to: 3) do: [ :each |
>      group button value: each.
>      html text: each ] ]
>
> #button would just be a short cut for "html radioButton group: self;
> yourself" (does the radio group know the renderer?).
>
> I guess #value: should be called something else, since #value: already
> outputs the actual HTML value attribute, but I'm not sure what to call
> it.
>
> Probably we need to keep most of the existing API for people to
> generate manual HTML that doesn't use callbacks (ie. #selected: and
> #value: on the radio buttons as well as #group:) but not sure if this
> implies two subclasses or just conditional behaviour based on whether
> a group is set.
>
> > I would prefer if you'd continued in a separate branch before merging
> > everything. Also I'd like to hear the comments of Julian and Philippe,
> > they didn't reply yet and might have other ideas. Also there is a
> > certain risk with so deep changes that potentially break a lot of code
> > so close to beta ...
>
> Heh, you did say it seemed almost ready to merge :) but I agree it may
> have been a bit quick in the end. Still I'm sure we can sort it out.
> Compatibility is certainly a good thing if we can manage it, though
> I'm reluctant to keep around *classes* for legacy purposes...
>
> What are our options, here? Can we keep #callback: around on radio
> buttons and have it store a (value?) callback as the associated value
> (as well as signal a deprecated notification). We'd have to special
> case the code in the radio group I suppose to execute the callback if
> it came up as the selected value. Would that work? Are there other
> solutions?
>
> Julian
> _______________________________________________
> seaside-dev mailing list
> seaside-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside-dev/attachments/20091231/003f6b24/attachment.htm