Implementing it as a mixin has few disadvantages, first of all the change event of the Select component always sets it's component value, generic mixin can't do that, I don't think it would be a good idea to have different behavior in the other form fields.
Next thing is that RadioGroup will have a different JS implementation based on finding all radio inputs by the group name, so mixin can't be used here. Only way is to bind the same zone to all group's radios. As I wrote before I don't think that a mixin should be used here. ZoneUpdater mixin sounds like a good idea but will require different approach. Denis On Aug 15, 2011, at 12:45 AM, Taha Hafeez wrote: > +1 for implementation mixin. Such an implementation with respect both > arguments. > > On Sun, Aug 14, 2011 at 11:40 PM, Bob Harner <[email protected]> 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 <[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] >> >> > > > > -- > Regards > > Taha Hafeez Siddiqi (tawus) > http://tawus.wordpress.com > > --------------------------------------------------------------------- > 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]
