tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Howard Lewis Ship <hls...@gmail.com>
Subject Re: Question about Tapestry internals... And congratulations!
Date Tue, 12 Feb 2013 00:29:27 GMT
The main use case is to support the activate event, where you may have
multiple implementations, i.e.

// Set up state, if necessary
void onActivate(MyEntity entity) ...

// Do security checks, etc.
void onActivate()

In addition, when there's an EventContext parameter, Tapestry can't
determine how many parameters are necessary to "satisfy" the method (the
way it can with explicit parameters).


In terms of the 404 support, I have thought that we could do a better job
of "cataloging" the activate event handler methods of a page class to
determine which requests apply, based on what extra path data is present in
the request.

To be honest, this is one area where Tapestry's built in logic is a bit
lacking, as it came together piecemeal over time. For instance, it would be
nice if ValueEncoder could express what kind of string data it can parse,
and it would also be nice if ComponentEventLinkEncoder had a way to provide
a sequence of potential PageRenderRequestParameters, or something,
to reflect what an incoming request might match against one page, or some
other index page in a parent folder, depending on what what in the extra
path.


On Sun, Feb 10, 2013 at 8:04 AM, Massimo Lusetti <mlusetti@gmail.com> wrote:

> I think i got it... Is to be able to get List, Object[] and EventContext
> as correct parameter inside onActivate methods... right?
>
>
> On Sat, Feb 9, 2013 at 7:25 PM, Massimo Lusetti <mlusetti@gmail.com>wrote:
>
>> Hi Howard,
>>   first of all big hug to you and your (now bigger) family... I've two
>> son one of which 6 months old and I know how happy you are now... Enjoy the
>> moment!
>>
>> Now the boring stuff ;-) ... I'm digging into some internals of Tapestry
>> to find a way to let the framework handle 404 requests, you may have read
>> the thread in the mailing list.
>>
>> Now the question: Why in the ComponentEventImpl class, you are checking
>> for parameter count with more or equals and not just equals? I mean this
>> peace of code:
>>
>> public boolean matches(String eventType, String componentId, int
>> parameterCount)
>>     {
>>         if (isAborted())
>>             return false;
>>
>>         return this.eventType.equalsIgnoreCase(eventType) &&
>> context.getCount() >= parameterCount
>>                 && (originatingComponentId.equalsIgnoreCase(componentId)
>> || componentId.equals(""));
>>     }
>>
>> starting at line 65 of ComponentEventImpl.
>>
>> I'm somehow curious to know which was the reason behind this choice since
>> I think this could and should be changed to let the platform better handle
>> requests with activation context to page without activation context
>> handlers methods.
>>
>> Cheers
>> --
>> Massimo
>>
>
>
>
> --
> Massimo
> http://meridio.blogspot.com
>



-- 
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message