You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Alessio Gambi <ag...@gmail.com> on 2010/10/24 08:29:46 UTC
On EventBubbling
Hi,
I would like to return a boolean value form the handler instead of
using the value of the boolean itself to control the bubbling process
(actually the same applies to void).
For this purpose, I defined an annotation to prevent events to bubble
for the annotated event handler methods, and a
ComponentClassTransformationWorker.
The first idea was to let the worker to modify the return value of the
original method to something wrapping the boolean (and the void) and
override its result. Unfortunately I did not find a way to do that.
The next idea is to add a new eventHandler method that listen for the
same events/components of the original one, it basically wraps the
body of the original method using an advide.
The problem now is to "register" this new method with the
dispatcherMethod. I think the best way is to annotate the method with
the OnEvent annotation and name it something like:
_+originalMethod name
In this way, this method should be always called before the original
one, always produces an Object that stops the bubbling, and always
invoke the same logic as the original method.
The problem: I cannot find a way to add the annotation to a generated
method.
In another possibility, I can name the new method with something like
on+MethodName. But, I do not remember if the annotation takes
precedence over the naming convention.
Anyway, this solution is not so clean (and there may be clashes or
method duplications).
Any advice ?
BTW, I am using 5.2
Thank you.
-- Alessio
PS: As far as possible, I would like the OnEventWorker to register
handler methods in the component event dispatcher.
Re: On EventBubbling
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Mon, 25 Oct 2010 14:53:09 -0200, Alessio Gambi <ag...@gmail.com>
wrote:
> Hi,
Hi!
> my use case is to use Tapestry as back end of GWT components, in
> particular the ones that use GWT RPC calls (that may have void and
> boolean as return type). Tapestry can be used in place of the server
> side GWT Servlet to intercept the calls and route them (as
> ComponentEvent) to components.
> More details can be found here.
> http://code.google.com/p/trsvax-gmt/
Reading the project goals page, I've found this: "Secondly GWT wants your
service to implement an interface and that's just not the Tapestry way."
Defining a service as an interface is the Tapestry and Tapestry-IoC
recommended way of doing things. ;)
--
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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: On EventBubbling
Posted by Alessio Gambi <ag...@gmail.com>.
Hi,
my use case is to use Tapestry as back end of GWT components, in
particular the ones that use GWT RPC calls (that may have void and
boolean as return type).
Tapestry can be used in place of the server side GWT Servlet to
intercept the calls and route them (as ComponentEvent) to components.
More details can be found here.
http://code.google.com/p/trsvax-gmt/
-- Alessio
On Oct 25, 2010, at 5:59 PM, Josh Canfield wrote:
> I don't understand the use case. Can you describe why you want to do
> this?
>
> On Mon, Oct 25, 2010 at 1:13 AM, Alessio Gambi <ag...@gmail.com>
> wrote:
>> Hi,
>> FYI.
>>
>> In the end I managed to have a working solution for altering the
>> behaviour
>> of event bubbling (limited to void, boolean and null values).
>>
>> My solution that I really do not appreciate so much... consists in:
>>
>> - Provide an annotation: @StopBubbling
>>
>> - Copy+Paste+Modify the OnEventWorker and do the following mods:
>> - at the beginning recover all the methods with the annotation
>> (blocked methods)
>> - for all the blocked methods wrap the contextEvent in a new
>> class to
>> force the event.isAborted to a true value, and the storeResult to
>> store a
>> wrapped Boolean, Null or Void.
>>
>> - Provide a contribution to ComponentEventProcessor to deal with
>> the new
>> types of objects
>>
>>
>> On Oct 24, 2010, at 7:54 PM, Howard Lewis Ship wrote:
>>
>>> The boolean logic is hard coded; perhaps you should think in terms
>>> of
>>> a enum to return instead.
>>>
>>> On Sat, Oct 23, 2010 at 11:29 PM, Alessio Gambi <ag...@gmail.com>
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I would like to return a boolean value form the handler instead
>>>> of using
>>>> the
>>>> value of the boolean itself to control the bubbling process
>>>> (actually the
>>>> same applies to void).
>>>> For this purpose, I defined an annotation to prevent events to
>>>> bubble for
>>>> the annotated event handler methods, and a
>>>> ComponentClassTransformationWorker.
>>>>
>>>> The first idea was to let the worker to modify the return value
>>>> of the
>>>> original method to something wrapping the boolean (and the void)
>>>> and
>>>> override its result. Unfortunately I did not find a way to do that.
>>>> The next idea is to add a new eventHandler method that listen for
>>>> the
>>>> same
>>>> events/components of the original one, it basically wraps the
>>>> body of the
>>>> original method using an advide.
>>>> The problem now is to "register" this new method with the
>>>> dispatcherMethod.
>>>> I think the best way is to annotate the method with the OnEvent
>>>> annotation
>>>> and name it something like:
>>>>
>>>> _+originalMethod name
>>>>
>>>> In this way, this method should be always called before the
>>>> original one,
>>>> always produces an Object that stops the bubbling, and always
>>>> invoke the
>>>> same logic as the original method.
>>>>
>>>> The problem: I cannot find a way to add the annotation to a
>>>> generated
>>>> method.
>>>>
>>>>
>>>> In another possibility, I can name the new method with something
>>>> like
>>>> on+MethodName. But, I do not remember if the annotation takes
>>>> precedence
>>>> over the naming convention.
>>>> Anyway, this solution is not so clean (and there may be clashes
>>>> or method
>>>> duplications).
>>>>
>>>> Any advice ?
>>>>
>>>> BTW, I am using 5.2
>>>>
>>>> Thank you.
>>>>
>>>> -- Alessio
>>>>
>>>> PS: As far as possible, I would like the OnEventWorker to register
>>>> handler
>>>> methods in the component event dispatcher.
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Howard M. Lewis Ship
>>>
>>> Creator of Apache Tapestry
>>>
>>> The source for Tapestry training, mentoring and support. Contact
>>> me to
>>> learn how I can get you up and productive in Tapestry fast!
>>>
>>> (971) 678-5210
>>> http://howardlewisship.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: On EventBubbling
Posted by Josh Canfield <jo...@gmail.com>.
I don't understand the use case. Can you describe why you want to do this?
On Mon, Oct 25, 2010 at 1:13 AM, Alessio Gambi <ag...@gmail.com> wrote:
> Hi,
> FYI.
>
> In the end I managed to have a working solution for altering the behaviour
> of event bubbling (limited to void, boolean and null values).
>
> My solution that I really do not appreciate so much... consists in:
>
> - Provide an annotation: @StopBubbling
>
> - Copy+Paste+Modify the OnEventWorker and do the following mods:
> - at the beginning recover all the methods with the annotation
> (blocked methods)
> - for all the blocked methods wrap the contextEvent in a new class to
> force the event.isAborted to a true value, and the storeResult to store a
> wrapped Boolean, Null or Void.
>
> - Provide a contribution to ComponentEventProcessor to deal with the new
> types of objects
>
>
> On Oct 24, 2010, at 7:54 PM, Howard Lewis Ship wrote:
>
>> The boolean logic is hard coded; perhaps you should think in terms of
>> a enum to return instead.
>>
>> On Sat, Oct 23, 2010 at 11:29 PM, Alessio Gambi <ag...@gmail.com>
>> wrote:
>>>
>>> Hi,
>>>
>>> I would like to return a boolean value form the handler instead of using
>>> the
>>> value of the boolean itself to control the bubbling process (actually the
>>> same applies to void).
>>> For this purpose, I defined an annotation to prevent events to bubble for
>>> the annotated event handler methods, and a
>>> ComponentClassTransformationWorker.
>>>
>>> The first idea was to let the worker to modify the return value of the
>>> original method to something wrapping the boolean (and the void) and
>>> override its result. Unfortunately I did not find a way to do that.
>>> The next idea is to add a new eventHandler method that listen for the
>>> same
>>> events/components of the original one, it basically wraps the body of the
>>> original method using an advide.
>>> The problem now is to "register" this new method with the
>>> dispatcherMethod.
>>> I think the best way is to annotate the method with the OnEvent
>>> annotation
>>> and name it something like:
>>>
>>> _+originalMethod name
>>>
>>> In this way, this method should be always called before the original one,
>>> always produces an Object that stops the bubbling, and always invoke the
>>> same logic as the original method.
>>>
>>> The problem: I cannot find a way to add the annotation to a generated
>>> method.
>>>
>>>
>>> In another possibility, I can name the new method with something like
>>> on+MethodName. But, I do not remember if the annotation takes precedence
>>> over the naming convention.
>>> Anyway, this solution is not so clean (and there may be clashes or method
>>> duplications).
>>>
>>> Any advice ?
>>>
>>> BTW, I am using 5.2
>>>
>>> Thank you.
>>>
>>> -- Alessio
>>>
>>> PS: As far as possible, I would like the OnEventWorker to register
>>> handler
>>> methods in the component event dispatcher.
>>>
>>>
>>>
>>
>>
>>
>> --
>> Howard M. Lewis Ship
>>
>> Creator of Apache Tapestry
>>
>> The source for Tapestry training, mentoring and support. Contact me to
>> learn how I can get you up and productive in Tapestry fast!
>>
>> (971) 678-5210
>> http://howardlewisship.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: On EventBubbling
Posted by Alessio Gambi <ag...@gmail.com>.
Hi,
FYI.
In the end I managed to have a working solution for altering the
behaviour of event bubbling (limited to void, boolean and null values).
My solution that I really do not appreciate so much... consists in:
- Provide an annotation: @StopBubbling
- Copy+Paste+Modify the OnEventWorker and do the following mods:
- at the beginning recover all the methods with the annotation
(blocked methods)
- for all the blocked methods wrap the contextEvent in a new class to
force the event.isAborted to a true value, and the storeResult to
store a wrapped Boolean, Null or Void.
- Provide a contribution to ComponentEventProcessor to deal with the
new types of objects
On Oct 24, 2010, at 7:54 PM, Howard Lewis Ship wrote:
> The boolean logic is hard coded; perhaps you should think in terms of
> a enum to return instead.
>
> On Sat, Oct 23, 2010 at 11:29 PM, Alessio Gambi <ag...@gmail.com>
> wrote:
>> Hi,
>>
>> I would like to return a boolean value form the handler instead of
>> using the
>> value of the boolean itself to control the bubbling process
>> (actually the
>> same applies to void).
>> For this purpose, I defined an annotation to prevent events to
>> bubble for
>> the annotated event handler methods, and a
>> ComponentClassTransformationWorker.
>>
>> The first idea was to let the worker to modify the return value of
>> the
>> original method to something wrapping the boolean (and the void) and
>> override its result. Unfortunately I did not find a way to do that.
>> The next idea is to add a new eventHandler method that listen for
>> the same
>> events/components of the original one, it basically wraps the body
>> of the
>> original method using an advide.
>> The problem now is to "register" this new method with the
>> dispatcherMethod.
>> I think the best way is to annotate the method with the OnEvent
>> annotation
>> and name it something like:
>>
>> _+originalMethod name
>>
>> In this way, this method should be always called before the
>> original one,
>> always produces an Object that stops the bubbling, and always
>> invoke the
>> same logic as the original method.
>>
>> The problem: I cannot find a way to add the annotation to a generated
>> method.
>>
>>
>> In another possibility, I can name the new method with something like
>> on+MethodName. But, I do not remember if the annotation takes
>> precedence
>> over the naming convention.
>> Anyway, this solution is not so clean (and there may be clashes or
>> method
>> duplications).
>>
>> Any advice ?
>>
>> BTW, I am using 5.2
>>
>> Thank you.
>>
>> -- Alessio
>>
>> PS: As far as possible, I would like the OnEventWorker to register
>> handler
>> methods in the component event dispatcher.
>>
>>
>>
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
>
> The source for Tapestry training, mentoring and support. Contact me to
> learn how I can get you up and productive in Tapestry fast!
>
> (971) 678-5210
> http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: On EventBubbling
Posted by Howard Lewis Ship <hl...@gmail.com>.
The boolean logic is hard coded; perhaps you should think in terms of
a enum to return instead.
On Sat, Oct 23, 2010 at 11:29 PM, Alessio Gambi <ag...@gmail.com> wrote:
> Hi,
>
> I would like to return a boolean value form the handler instead of using the
> value of the boolean itself to control the bubbling process (actually the
> same applies to void).
> For this purpose, I defined an annotation to prevent events to bubble for
> the annotated event handler methods, and a
> ComponentClassTransformationWorker.
>
> The first idea was to let the worker to modify the return value of the
> original method to something wrapping the boolean (and the void) and
> override its result. Unfortunately I did not find a way to do that.
> The next idea is to add a new eventHandler method that listen for the same
> events/components of the original one, it basically wraps the body of the
> original method using an advide.
> The problem now is to "register" this new method with the dispatcherMethod.
> I think the best way is to annotate the method with the OnEvent annotation
> and name it something like:
>
> _+originalMethod name
>
> In this way, this method should be always called before the original one,
> always produces an Object that stops the bubbling, and always invoke the
> same logic as the original method.
>
> The problem: I cannot find a way to add the annotation to a generated
> method.
>
>
> In another possibility, I can name the new method with something like
> on+MethodName. But, I do not remember if the annotation takes precedence
> over the naming convention.
> Anyway, this solution is not so clean (and there may be clashes or method
> duplications).
>
> Any advice ?
>
> BTW, I am using 5.2
>
> Thank you.
>
> -- Alessio
>
> PS: As far as possible, I would like the OnEventWorker to register handler
> methods in the component event dispatcher.
>
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org