On Tue, Feb 12, 2013 at 1:29 AM, Howard Lewis Ship <[email protected]> wrote:
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() > > I must admit I've never used onActivate to do security checks... > 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). > Yes I know that... EventContext, Object[] and List. The last two are somehow deprecated now so we can treat the EventContext as a way for the page to declare: "I want to handle it myself, let me do it". > > 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. > > Agreed. I see this service as a sort of Dispatcher, a two level dispatcher that could lookup the page first then the parameters. There's the need to decide which is the correct possible lookup order in terms of parent/child folder. -- Massimo
