Hi Thiago, thanks, I know this. The block switching is only a bit better if-then-else. Imagine, that I like to have more than one area customized for the teams/team case. There, I will end up with multiple block switchings.
And my page still has two times as much components plus the switchings as the more elegant solution with two separate pages. I think tapestry could benefit from a really good thought out URL indirection layer which should be optional of course. Something like @UriTemplate at page class level would be really nice. See your own thread from last year: http://markmail.org/thread/pk2sv5lmtyk74k46 especially the post from Kristian Marinkovic http://markmail.org/message/wkbu5tdq2poja3tz, which needed the exactely URL scheme as I do. But I also see the problem Howard pointed at http://markmail.org/message/nxvn2cpiyq7sfyta. I think, on one hand we have the principle a class should do one thing and only one thing. So it is perfectly to understand that the pages/Articles class would return a list of all articles and the pages/Article class would return exactly one article needing a activation context to do so. On the other hand we have this well understood hierarchical directory concept where a directory like articles would contain all articles known and the file articles/foo the special article foo. The names of resources in REST mirror this directory concept and beside that a "hackable" URL should also follow this concept. How can we merge the two? To make it more clear, here are the hierarchical URLs: * /customers/ list all customers * /customers/{c-id}/ show one customer * /customers/{c-id}/orders/ list all orders of the customer * /customers/{c-id}/orders/{o-id}/ show one order of the customer and here the page classes: * pages/Customers * pages/Customer with activation context {c-id} * pages/Orders with activation context {c-id} * pages/Order with activation context {c-id} and {o-id} The URLs of the classes would be: * /customers * /customer/{c-id} * /orders/{c-id} * /order/{c-id}/{o-id} I think, in Tapestry, we have services (the pages) which are able to deliver a response on behalf of some activation context parameters. In REST we have resources which can be displayed by a GET on the particular URI. In REST /customer/{c-id}/ is a resource and /customer/{c-id}/orders/ is also one. It's like static files laying around. In REST where would be also the resource /orders/ which would simply list all orders of the store. So not all resources are structured hierarchical. But in Tapestry we have more of a SOA. We have a Orders class which can display some list of orders depending on its activation context. There is also no way to have such a thing like a dynamic class like /customers/{c-id}. So is Tapestry SOA and can't speak REST? Best Regards Alex On Sun, 2010-02-21 at 17:40 -0300, Thiago H. de Paula Figueiredo wrote: > On Sun, 21 Feb 2010 16:19:58 -0300, Alexander Kiel <alexanderk...@gmx.net> > wrote: > > > ok this is possible. But than I have at least one big if-then-else > > statement in my page and that page has both components loaded, a grid > > and a beandisplay (if we stay simple). If I use two separate pages, I > > have no if-then-else nightmare and my pages are much lighter. > > Just create one <t:block> for each possible rendering and then use the > Delegate component to render one of them. No big if-then-else needed. This > approach is described here: > http://tapestry.apache.org/tapestry5.1/cookbook/switch.html > -- mobile: +49 (0) 176 6152 9741 phone: +49 (0) 341 2289 188 e-mail: alexanderk...@gmx.net web: www.alexanderkiel.net
signature.asc
Description: This is a digitally signed message part
