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

[Julian Fitzell]

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