Thiago,
I guess you want the Class if your doing annotation based protection,
and the string if you have some sort of map. But, as Daniel mentioned,
you can get a ComponentSource, and convert the string to a Class, so no
problems there.
The problem is deciding what a normally dispatched request is.
Tapestry's whole philosophy is that my dispatcher/Service/Component is
as normal as any other dispatcher/Service/Component. Just today I saw
some messages about more RESTful URLs, that get converted to a page with
parameters. Any dispatcher that converts the request to a Page/Component
class will need to be involved in the complete solution.
Hmm, interesting design problem. It's after midnight here, so maybe I'll
think some more tomorrow.
Ciao,
Jonathan
On 05/02/2009 20:51, Thiago H. de Paula Figueiredo wrote:
Em Thu, 05 Feb 2009 15:20:02 -0300, Jonathan O'Connor
<ninki...@eircom.net> escreveu:
Thiago,
Hi!
I thought about the service idea, but what would it look like?
Class extractPageClass(String requestPath) would be what I'd want.
That's what I want too. I would add a String extractPageName(String
requestPath), returning the Tapestry page name (something like
admin/user/edit).
However, for each Dispatcher, you'd want a PageClassExtracter as
well, and I'm sure there'd be lots of duplication.
I haven't thought of the dispatcher issue yet, but maybe we could
suppose that our new service would deal only with normally-dispatched
requests.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
