> I see the implementation of both very similar: almost just JavaScript, listen > to a change event and use ZoneManager to update a zone passing a value as > context (the selected value in Select, true or false in Checkbox and Radio, > select value for RadioGroup). The JavaScript code would figure out what to do > based on the type of HTML form component (or any component implementing > ClientElement instance) in which the mixin was applied. We could even have a > generic ZoneUpdater mixin that updates a zone and that could be used in any > component or HTML element (in this case, the Any component should be used).
I Agree now :). It would be better to have to have a ZoneUpdater mixin even though I still think that one param is more lazy dev friendly :). > I haven't seen your patches, though. I will try to implement it. Denis On 12.8.2011, at 22:30, Thiago H. de Paula Figueiredo wrote: > On Fri, 12 Aug 2011 15:49:05 -0300, Denis Stepanov <[email protected]> > wrote: > >> I understand mixin concept and code separation but in this case I don't >> think we need discuss so much about a few lines of code. > > I disagree. :) > >> We can also discuss that Autocomplete should be somehow wired with all that >> onchange actions because it does the same thing. > > I'm not following you here. I just presented Autocomplete as something that > could be implemented inside the component but it was decided that it was best > implemented as a mixin. IMHO that's the approach we should follow. > >> IMHO mixin is too abstract for two different form components. > > I see the implementation of both very similar: almost just JavaScript, listen > to a change event and use ZoneManager to update a zone passing a value as > context (the selected value in Select, true or false in Checkbox and Radio, > select value for RadioGroup). The JavaScript code would figure out what to do > based on the type of HTML form component (or any component implementing > ClientElement instance) in which the mixin was applied. We could even have a > generic ZoneUpdater mixin that updates a zone and that could be used in any > component or HTML element (in this case, the Any component should be used). > > I haven't seen your patches, though. > >> Select component already has a zone parameter > > That's my point: it shouldn't have a zone parameter and IMHO we shouldn't > propagate this error to any other component. > >> The question is should other form components like Checkbox support similar >> behaviour using same approach simply by binging a zone parameter? > > I don't think so. > > -- > Thiago H. de Paula Figueiredo > Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and > instructor > Owner, Ars Machina Tecnologia da Informação Ltda. > http://www.arsmachina.com.br --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
