tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bob Harner <bobhar...@gmail.com>
Subject Re: ValueChanged event from RadioGroup and Checkbox
Date Sat, 13 Aug 2011 18:54:42 GMT
Support for zones seems to me to be a core function of Tapestry and
thus seems to me relevant for most of the form input components. Since
the ActionLink, EventLink, Select and Form components already use the
"zone" attribute rather than via mixins, I think it's important to be
consistent with the other components like radio and checkbox.

On Sat, Aug 13, 2011 at 10:18 AM, Andreas Andreou <andreoua@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.drobiazko@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.stepanov@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.stepanov@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-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>
>>>
>>
>>
>> --
>> Best regards,
>>
>> Igor Drobiazko
>> http://tapestry5.de
>>
>
>
>
> --
> Andreas Andreou - andyhot@apache.org - http://blog.andyhot.gr
> Apache Tapestry PMC / http://chesstu.be owner
> Open Source / JEE Consulting
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org


Mime
View raw message