What about making a new class for <br>e.g. called WARadioGroupTag.<br>In that case i would change back the code for WARadioGroup.<br><br>The code would be similar to the select lists:<br><br> html radioGroupList<br>               list: self elements;<br>
               selected: self selected;<br>               callback: [ :value | selected := value ]<br><br>BTW how to get the group from button. There is no direct reference or am i missing something.<br><br>Gerhard<br><br>
<div class="gmail_quote">On Wed, Dec 30, 2009 at 9:42 PM, Julian Fitzell <span dir="ltr">&lt;<a href="mailto:jfitzell@gmail.com">jfitzell@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On Wed, Dec 30, 2009 at 10:01 AM, Lukas Renggli &lt;<a href="mailto:renggli@gmail.com">renggli@gmail.com</a>&gt; wrote:<br>
&gt; I think this is a good improvement, but we have to be careful.<br>
&gt; Behavior seems to be a bit distributed at the moment, for example the<br>
&gt; callback is on the group but the selection is still on the individual<br>
&gt; options?<br>
<br>
</div>I had the same response to the selection being on the radio group. I<br>
also don&#39;t like having to call #valueFor: on the radio group when<br>
passing in the value; since the button knows the group, you should<br>
just be able to pass in the object you want associated with it and<br>
have the radio button deal with getting a unique key from the group. I<br>
also then wondered whether it wouldn&#39;t be nicer to get the button from<br>
the group. So all put together it might look something like:<br>
<br>
html radioGroup<br>
  callback: [ :value | self setFoo: value ];<br>
  selection: self getFoo;<br>
  with: [ :group |<br>
    (1 to: 3) do: [ :each |<br>
      group button value: each.<br>
      html text: each ] ]<br>
<br>
#button would just be a short cut for &quot;html radioButton group: self;<br>
yourself&quot; (does the radio group know the renderer?).<br>
<br>
I guess #value: should be called something else, since #value: already<br>
outputs the actual HTML value attribute, but I&#39;m not sure what to call<br>
it.<br>
<br>
Probably we need to keep most of the existing API for people to<br>
generate manual HTML that doesn&#39;t use callbacks (ie. #selected: and<br>
#value: on the radio buttons as well as #group:) but not sure if this<br>
implies two subclasses or just conditional behaviour based on whether<br>
a group is set.<br>
<div class="im"><br>
&gt; I would prefer if you&#39;d continued in a separate branch before merging<br>
&gt; everything. Also I&#39;d like to hear the comments of Julian and Philippe,<br>
&gt; they didn&#39;t reply yet and might have other ideas. Also there is a<br>
&gt; certain risk with so deep changes that potentially break a lot of code<br>
&gt; so close to beta ...<br>
<br>
</div>Heh, you did say it seemed almost ready to merge :) but I agree it may<br>
have been a bit quick in the end. Still I&#39;m sure we can sort it out.<br>
Compatibility is certainly a good thing if we can manage it, though<br>
I&#39;m reluctant to keep around *classes* for legacy purposes...<br>
<br>
What are our options, here? Can we keep #callback: around on radio<br>
buttons and have it store a (value?) callback as the associated value<br>
(as well as signal a deprecated notification). We&#39;d have to special<br>
case the code in the radio group I suppose to execute the callback if<br>
it came up as the selected value. Would that work? Are there other<br>
solutions?<br>
<font color="#888888"><br>
Julian<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
seaside-dev mailing list<br>
<a href="mailto:seaside-dev@lists.squeakfoundation.org">seaside-dev@lists.squeakfoundation.org</a><br>
<a href="http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev" target="_blank">http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev</a><br>
</div></div></blockquote></div><br>