My reading of REST is that it is about actions (GET, POST, PUT, DELETE, etc) on 
resources, not the requesting of pages that invoke those actions.  So the 
question becomes what are appropriate URLs for *pages* that can invoke the 
actions of create, view, edit, view, search, etc.? 

I like the aim of making URLs comprehensible to the user and navigable by the 
user, and I think we can get close with this kind of thing...

URL                                             Implementation
/customers/                                     pages/customers/Index
/customers/search                       pages/customers/Search
/customers/new                          pages/customers/New
/customers/view/{c-id}                  pages/customers/View
/customers/edit/{c-id}                  pages/customers/Edit
/customers/delete/{c-id}                pages/customers/Delete
/customers/orders                       pages/customers/orders/Index
/customers/orders?c={c-id}      pages/customers/orders/Index
/customers/orders/new/{c-id}    pages/customers/orders/New
/customers/orders/view/{o-id}   pages/customers/orders/View
etc...

...or maybe it would be better to treat orders as a resource which has customer 
as an attribute...

/orders                                         pages/customers/orders/Index
/orders?c={c-id}                                pages/customers/orders/Index
/orders/new/{c-id}                              pages/customers/orders/New
/orders/view/{o-id}                     pages/customers/orders/View
/orders/edit/{o-id}                             pages/customers/orders/Edit
/orders/delete/{o-id}                   pages/customers/orders/Delete

It's a compromise based on the premise that there isn't actually a RESTful URL 
scheme suited to requesting web pages (at least I've never seen one). What do 
you think?

Cheers,

Geoff

On 21/02/2010, at 9:11 PM, Alexander Kiel wrote:

> Hi Tapestry users and devs,
> 
> this is my first question here and I use Tapestry for only three days
> now, so excuse my question if there is already a documented answer.
> 
> Suppose, I want to implement an online store with Tapestry. I like to
> have the following URLs:
> 
> * /articles/                         list all articles available
> * /articles/{a-id}/                  show one article
> * /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
> 
> If I create a class Articles under the pages package, I can implement
> the /articles/ URL. But than, the /articles/{a-id}/ URL will also point
> to the Articles page. The a-id will be the activation context of the
> Articles page. I could fork between displaying one article and
> displaying a list of all articles in one page, but I don't like to do
> that and I don't think one should use Tapestry this way. So I need a
> separate page for displaying one article.
> 
> I like to have an Articles page without activation context and an
> Article page with activation context. I can do so but than I end up with
> the following URLs:
> 
> * /articles/
> * /article/{a-id}/
> 
> This breaks the hierarchy, I want to install. I want hackable URLs [1]
> so they have to be hierarchical.
> 
> The next best thing I could do is create a articles package under pages
> and put there an Index page and a Article page. This would give me:
> 
> * /articles/
> * /articles/article/{a-id}/
> 
> This is not bad but the additional article path is just redundant. To
> remove this redundant part, I used an URLRewriterRule. Without posting
> the code here, I simply added the article part in the inbound filter and
> removed it in the outbound one. This works finally and I get my URL
> scheme:
> 
> * /articles/
> * /articles/{a-id}/
> 
> But I have not tested my filter with action and event links yet and it
> is still possible to access articles under /articles/article/{a-id}/ so
> I have to add a filter which redirects to the /articles/{a-id}/ URL
> because I don't want that someone bookmarks this not official
> supported /articles/article/{a-id}/ URL.
> 
> The next big thing are the customer URLs described above. I think I
> could hack some combination of URLRewriterRules and Pages which parse
> two ids out of one activation context, but I don't like to missuse well
> thought out architectures.
> 
> 
> Thanks for your help
> Alex
> 
> 
> [1]: <http://www.useit.com/alertbox/990321.html> 
> 
> -- 
> e-mail: alexanderk...@gmx.net
> web:    www.alexanderkiel.net
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Reply via email to