I'm really opposed to this. It is One More Choice to Make and that's a bad thing. Addiing lots of options that can be enabled or disabled is a cop out, if a feature needs to be disabled, it is likely broken. I'm only leaving in the "optimized request" stuff so that I can prove its not worth using (!).
I want there to be a rigid, predictable set of rules for mapping between URLs and class names, not an endless series of decisions. I'm picturing this from a support angle, as in, limiting the number of questions I'd have to ask a prospective client. Some amount of configuration and tuning is unavoidable, but I think making major behaviors of the application optional will ultimately be worse than making people work around, or otherwise adapt to, Tapestry's naming rules. And it gets worse for IDEs that want to keep up with Tapestry. On Feb 11, 2008 1:08 PM, Daniel Jue <[EMAIL PROTECTED]> wrote: > How about a flag in the app module to just turn off the friendly page > renaming altogether? Then if someone wants to have a > page structure like > > report/status > report/reportstatus > report/statusreport > report/statusreport1 > > They can all resolve to unique pages. > > For now, I'll add the contents of my old post to the Caveats wiki > http://wiki.apache.org/tapestry/Tapestry5Caveats > > > On Feb 11, 2008 3:36 PM, 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] > > > > > > > > > > > > > > -- > > Howard M. Lewis Ship > > > > Creator Apache Tapestry and Apache HiveMind > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
