Whether you implement that feature as a mixin or as a component's parameter is probably a matter of taste. But I have two concerns implementing about a mixin:
1) I think everybody will agree that inconsistent API sucks. If you are used to use zone parameter for ajaxifying ActionLink, Form, Select, etc, you would expect the Checkbox component to behave same. Having a consistent API is much more important that the fact that "zone is orthogonal to the core components' functionality". 2) Currently, when I need to explain somebody how to ajaxify a component it tell him to use zone parameter. Using this parameter is very simple. Even Tapestry beginners are happy with it. In the last 8 months I teached a lot of non-Java developers. They start to ask about Ajax after a couple of hours using Tapestry. In order to get started with Ajax, they just need to learn what is a zone and how to connect it to a component, such as ActionLink. That's all. 3) Now imagine how that would change if you would need to use mixins: First of all, you would need to use two parameters for a component(t:mixins="FooMixin" and FooMixin.zone="myZone"). Using just zone="myZone" is much more simple. Over overcomplicating things? Now let's try to explain how to ajaxify a component to a Tapestry beginner. You tell him about using FooMixin. Oh, wait. You need to explain the mixin concept first. Not that easy for a Tapestry beginners. I'm pretty sure that even advanced users don't feel comfortable about mixins. That's just reality. Much as I like mixins, I strongly believe we should not use the concept in this case. On Sat, Aug 13, 2011 at 4:18 PM, Andreas Andreou <[email protected]> wrote: > I'm thinking that zone (and ajax) is orthogonal to the core > components' functionality. And > that's exactly where mixins are supposed to be good at. > > Now that doesn't mean that those components cannot directly offer the > zone parameter > to their users (this can still be the case) - it's just they will have > implemented that through > a mixin. > > The context parameter of ActionLink, EventLink was implemented through > inheritance > (in the way AbstractComponentEventLink is used) so i'm not sure if > it's a good counter-case > here. > > > On Sat, Aug 13, 2011 at 11:43, Igor Drobiazko <[email protected]> > wrote: > > -1 for implementing it as a mixin. We should keep consisten API for > > components. Almost every component has a zone parameter. Why should Radio > > and Checkbox behave different? > > > > Following this idea we should also have implemented context parameter of > > ActionLink, EventLink, etc as a mixin but we didn't. Why? Just because it > > doesn't make sense. Same for the current patch. > > > > IMHO, the patch should be applied as it is. We shouldn't use mixins just > > because we can. The zone parameter is definitely a part of the component. > > > > On Sat, Aug 13, 2011 at 10:30 AM, Denis Stepanov > > <[email protected]>wrote: > > > >> > 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] > >> > >> > > > > > > -- > > Best regards, > > > > Igor Drobiazko > > http://tapestry5.de > > > > > > -- > Andreas Andreou - [email protected] - http://blog.andyhot.gr > Apache Tapestry PMC / http://chesstu.be owner > Open Source / JEE Consulting > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Best regards, Igor Drobiazko http://tapestry5.de
