Yeah. I just think following the friendly URLs to their logical conclusion would dictate that the most common action would be mapped to that subroot URL.
In this case, though, I really think just simply extending the Start class convention to all packages would take care of the problem. You'd still have the clash between page names that are the same as subpackage names, but I'm hard-pressed to think of a legitimate situation there that wouldn't be addressed by having "index" URLs. -- Kevin On 2/11/08 3:36 PM, in article [EMAIL PROTECTED], "Howard Lewis Ship" <[EMAIL PROTECTED]> wrote: > I agree this is a tripping point that needs addressing. > > I tend to organize things a little differently, so I'd have an orders > package, with ListOrders, ViewOrders and EditOrders classes, thus: > > http://localhost/orders/list > http://localhost/orders/view/101 > http://localhost/orders/edit/101 > > > On Feb 11, 2008 10:07 AM, Kevin Menard <[EMAIL PROTECTED]> wrote: >> I ran into the same problem early on, and eventually just changed the name >> of my pages. What I wanted was to be able to have a URL hierarchy like the >> following: >> >> http://localhost/orders >> http://localhost/orders/view/101 >> http://localhost/orders/edit/101 >> >> There was no clear way to have an "index" page, like Start functions as in >> the root package. So, I naturally added an "Orders" page. All subsequent >> page accesses were viewed as activation context, however, so that fell >> apart. >> >> I sorta forgot about all this and hoped it had been fixed. If not, it'd be >> great if it could be, as it seems to be a tripping point for a lot of >> people. >> >> -- >> Kevin >> >> >> On 2/10/08 3:52 PM, in article >> [EMAIL PROTECTED], "Howard Lewis >> >> Ship" <[EMAIL PROTECTED]> wrote: >> >>> That's a very good point; I think it indicates that the approach taken >>> by Tapestry when recognizing page names is too simplistic. Instead of >>> trying to match forward, it should match backward, or perhaps create a >>> Trie structure from the available page names.† >>> >>> On Feb 9, 2008 1:37 PM, nillehammer <[EMAIL PROTECTED]> wrote: >>>> Hello fellow users, >>>> >>>> I have just faced a little problem. I have searched the online >>>> documentation >>>> of tapestry 5, this maillist and google for a solution. As I did not find >>>> anything apropriate, I think this might be worth a mail. >>>> >>>> I obviously chose a very stupid packages/classes hirarchy: >>>> eu.domain.app.pages.Menu.java >>>> eu.domain.app.pages.menu.Subpage1.java >>>> eu.domain.app.pages.menu.Subpage2.java >>>> >>>> This results in logical page names (and corresponding URLs): >>>> menu >>>> menu/subpage1 >>>> menu/subpage2 >>>> >>>> Now clicking a link ...menu/subpage1 or .../menu/subpage2 neither of the >>>> two >>>> pages ever loads. The page named menu allways shows up. I guess this >>>> behaviour occours, because the remaining part of the URL after "menu/" is >>>> handed to the page named menu as context rather than requesting the >>>> subpages. >>>> So do not do this. >>>> >>>> Kind regards, nillehammer >>>> >>>> P.S. My standing ovations to the tapestry developers. They have given the >>>> term >>>> "straight forward" a whole new meaning. Keep up the great work! THX >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>> >>>> >>> >>> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
