Hi Thiago, Thanks for your response. My replies inline below. -Mike > Why aren't the Tapestry URLs RESTful enough for your scenario? Using PUT, > DELETE, etc? Just curious. :)
I may be using the term 'RESTful' incorrectly. What I meant is suppose I have a page that displays the details of an order item, order ID is 5 and item number is 2. Out of the box, Tapestry uses URLs like 'http://host:port/appcontext/OrderItemDetails/5/2'. We want URLs like 'http://host:port/appcontext/order/5/item/2'. So the path has nothing to do with my fully qualified page class name and the parameters don't have to come at the end of the URL. Make sense? > Why [do you want to extend this to event URLs]? Event URLs aren't meant to be > used outside Tapestry applications themselves. I think the main idea is that we'd like the links that users see on hover to not look so radically different from the page URLs. It may be enough to make sure that the event URLs have the page part of the path in our desired format and the event part of the path can be in standard Tapestry format, e.g. '/order/5/item/2<http://host:port/appcontext/order/5/item/2>.remove'. We may not also require that the event part of the path be non-standard, e.g. '/order/5/item/2/remove'. > You can't do [that] directly. Instead, you'll need to use the LinkTransformer > API to rewrite the component event links to what you want. I don't think LinkTransformer will do anything more than ComponentEventLinkEncoder, which has pretty much the same 4 methods for both decoding page and component event requests, and creating/transforming links for page and component event requests. Creating/Transforming the links is absolutely working, but since the links I build for events do not conform to what Tapestry expects – i.e. look like ‘pathtopage.eventid’ – the click of the link isn’t recognized as a component event request.
