Ah, an implementation mixin. I forgot about those. I withdraw my objection if the mixin can be made to work this way.
On Sun, Aug 14, 2011 at 7:56 AM, Andreas Andreou <[email protected]> wrote: > Hi, on my way out so just a quick reply... > > If this is a mixin (and i'm thinking something that uses > Tapestry.Initializer.updateZoneOnEvent and has 2 parameters, zone and > eventName) > then it can be applied by default in all AbstractField subclasses > (the way that the RenderDisabled mixin applies to AbstractTextField > subclasses) > > So, users will still just write zone="myZone" > > And of course, they'll be able to reuse the mixin in their own components. > > > On Sun, Aug 14, 2011 at 12:07, Igor Drobiazko <[email protected]> > wrote: >> 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 >> > > > > -- > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
