+1 for implementation mixin. Such an implementation with respect both arguments.
On Sun, Aug 14, 2011 at 11:40 PM, Bob Harner <bobhar...@gmail.com> wrote: > 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 <andre...@gmail.com> 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 <igor.drobia...@gmail.com> >> 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 <andre...@gmail.com> 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 <igor.drobia...@gmail.com> >>>> 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 >>>> > <denis.stepa...@gmail.com>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 < >>>> >> denis.stepa...@gmail.com> 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: dev-unsubscr...@tapestry.apache.org >>>> >> For additional commands, e-mail: dev-h...@tapestry.apache.org >>>> >> >>>> >> >>>> > >>>> > >>>> > -- >>>> > Best regards, >>>> > >>>> > Igor Drobiazko >>>> > http://tapestry5.de >>>> > >>>> >>>> >>>> >>>> -- >>>> Andreas Andreou - andy...@apache.org - http://blog.andyhot.gr >>>> Apache Tapestry PMC / http://chesstu.be owner >>>> Open Source / JEE Consulting >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org >>>> For additional commands, e-mail: dev-h...@tapestry.apache.org >>>> >>>> >>> >>> >>> -- >>> Best regards, >>> >>> Igor Drobiazko >>> http://tapestry5.de >>> >> >> >> >> -- >> Andreas Andreou - andy...@apache.org - http://blog.andyhot.gr >> Apache Tapestry PMC / http://chesstu.be owner >> Open Source / JEE Consulting >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: dev-h...@tapestry.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > > -- Regards Taha Hafeez Siddiqi (tawus) http://tawus.wordpress.com --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
