Mailing-List: contact dev-help@tapestry.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tapestry development" <dev@tapestry.apache.org>
Received-SPF: pass (athena.apache.org: domain of bobharner@gmail.com
 designates 209.85.220.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAHzi-=nkRBDLmXSm+hPjTf5dCyhGwE9gAfP2PuDfJDkTC7YGjg@mail.gmail.com>
References: <op.vz4a8p1g18r83n@localhost.localdomain>
	<B242EE19-6468-4986-ACB2-0CF79B8A2B34@gmail.com>
	<CAB36eAwEPUP3UBL=t7ieo0s91BYmTetvxeNk7sP=pbqyyUjcRg@mail.gmail.com>
	<CAHzi-=nkRBDLmXSm+hPjTf5dCyhGwE9gAfP2PuDfJDkTC7YGjg@mail.gmail.com>
Date: Sat, 13 Aug 2011 14:54:42 -0400
Message-ID: 
 <CAHVWr9W5bko9Q0CDNzuAHCY4Ya-puX492p+7H0cBDSEPqS4X_Q@mail.gmail.com>
Subject: Re: ValueChanged event from RadioGroup and Checkbox
From: Bob Harner <bobharner@gmail.com>
To: Tapestry development <dev@tapestry.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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> wrot=
e:
> 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 Radi=
o
>> 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 i=
t
>> 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 Checkb=
ox
>>> and Radio, select value for RadioGroup). The JavaScript code would figu=
re
>>> out what to do based on the type of HTML form component (or any compone=
nt
>>> implementing ClientElement instance) in which the mixin was applied. We
>>> could even have a generic ZoneUpdater mixin that updates a zone and tha=
t
>>> 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 do=
n'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 a=
ll
>>> that onchange actions because it does the same thing.
>>> >
>>> > I'm not following you here. I just presented Autocomplete as somethin=
g
>>> 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 fol=
low.
>>> >
>>> >> 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 Checkb=
ox
>>> and Radio, select value for RadioGroup). The JavaScript code would figu=
re
>>> out what to do based on the type of HTML form component (or any compone=
nt
>>> implementing ClientElement instance) in which the mixin was applied. We
>>> could even have a generic ZoneUpdater mixin that updates a zone and tha=
t
>>> 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 shoul=
dn'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 paramete=
r?
>>> >
>>> > I don't think so.
>>> >
>>> > --
>>> > Thiago H. de Paula Figueiredo
>>> > Independent Java, Apache Tapestry 5 and Hibernate consultant, develop=
er,
>>> and instructor
>>> > Owner, Ars Machina Tecnologia da Informa=E7=E3o 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