The zone parameter is easy to use but not very flexible. I wrote a
bind mixin for jQuery that hooks events to pretty much anything. I
suspect you could do the same thing in Prototype. Bind is subclassed
to the event you want to capture so multiple events can be attached to
a single element. Here is
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 ha
+1 for implementation mixin. Such an implementation with respect both
arguments.
On Sun, Aug 14, 2011 at 11:40 PM, Bob Harner 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, Andre
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 wrote:
> Hi, on my way out so just a quick reply...
>
> If this is a mixin (and i'm thinking something that uses
> Tapestry.Initia
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 A
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
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
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
-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.
> 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 figu
> Autocomplete is a mixin, not logic embedded inside TextField, maybe more than
> 99% used just with TextField and people still manage to find and use it. It's
> just a matter of documentation. With a promise of backward compatibility so
> important as it is to Tapestry, we always have to use th
On Fri, 12 Aug 2011 13:04:02 -0300, Denis Stepanov
wrote:
But most probably Checkbox and Radio will have the same initialization.
Radio is more complicated and needs more code because of IE change event
bug, also it would be nice to have a zone parameter on RadioGroup.
Prototype and jQu
> But most probably Checkbox and Radio will have the same initialization.
Radio is more complicated and needs more code because of IE change event bug,
also it would be nice to have a zone parameter on RadioGroup.
I can't understand why anyone would want a mixin in this case, it can't be
reused
On Fri, 12 Aug 2011 06:03:38 -0300, Denis Stepanov
wrote:
Perhaps the patch should be to make select component do it as a mixin
;)
I don't want to break backwards compatibility,
Nor we.
Select nad Checkbox component need to have different JS init and
onChange method, I don't see any a
On Thu, 11 Aug 2011 17:01:42 -0300, Denis Stepanov
wrote:
What about a mixin instead of changing the component themselves? That's
what I'd do.
Select component doesn't implement it using a mixin.
But it should have been implemented as a mixin in first place. I don't
think this error sh
> Thanks, I have implemented this by using a mixin in our code.
>>>>>>>
>>>>>>> I just what to have native support for Radio and Checkbox valueChaned
>>>>>>> event in the next Tapestry version.
>>>>>>>
n our code.
>>>>>>
>>>>>> I just what to have native support for Radio and Checkbox valueChaned
>>>>>> event in the next Tapestry version.
>>>>>>
>>>>>> Denis
>>>>>>
>>>>>>
;>>> Thanks, I have implemented this by using a mixin in our code.
>>>>>
>>>>> I just what to have native support for Radio and Checkbox valueChaned
>>>>> event in the next Tapestry version.
>>>>>
>>>>> Denis
>>
gt;>> Denis
>>>>
>>>> On Aug 8, 2011, at 10:39 AM, Михаил Слободянюк wrote:
>>>>
>>>>>>
>>>>>> If you want use radio as like select try this
>>>>>> http://code.google.com/p/orion-cpu/source/browse/tru
AM, Михаил Слободянюк wrote:
If you want use radio as like select try this
http://code.google.com/p/orion-cpu/source/browse/trunk/orion-web/src/main/java/ua/orion/web/components/RadioSelect.java
I would like to add support for the valueChanged event from
RadioGroup and
Checkbox component just lik
;>> If you want use radio as like select try this
>>>> http://code.google.com/p/orion-cpu/source/browse/trunk/orion-web/src/main/java/ua/orion/web/components/RadioSelect.java
>>>>
>>>> I would like to add support for the valueChanged event from RadioGroup
src/main/java/ua/orion/web/components/RadioSelect.java
>>>
>>> I would like to add support for the valueChanged event from RadioGroup and
>>>> Checkbox component just like it is in Select component, is there anyone who
>>>> thinks it should be done and eventua
this
>> http://code.google.com/p/orion-cpu/source/browse/trunk/orion-web/src/main/java/ua/orion/web/components/RadioSelect.java
>>
>> I would like to add support for the valueChanged event from RadioGroup and
>>> Checkbox component just like it is in Select component, is t
>
> If you want use radio as like select try this
> http://code.google.com/p/orion-cpu/source/browse/trunk/orion-web/src/main/java/ua/orion/web/components/RadioSelect.java
>
> I would like to add support for the valueChanged event from RadioGroup and
>> Checkbox component just
Hi!
If you want use radio as like select try this
http://code.google.com/p/orion-cpu/source/browse/trunk/orion-web/src/main/java/ua/orion/web/components/RadioSelect.java
I would like to add support for the valueChanged event from RadioGroup and
> Checkbox component just like it is in Sel
Hi,
I would like to add support for the valueChanged event from RadioGroup and
Checkbox component just like it is in Select component, is there anyone who
thinks it should be done and eventually will accept a patch?
Denis
-
To
26 matches
Mail list logo
