Hi Guys, I agree with Howard. I think tapestry's behaviour of mapping URLs to page classes is good enough to be left as is. It is pretictable and easy to use... at least looking back from now.
The day I had the problem I was a little confused not having totally understood everything. A hint in the doc would have spared me some hours of tumbling around. And as I neither have found anything covering my problem in the maillist, I wanted to share my experience so that future users would find my mail and get a bit quicker past this silly mistake than me. So again dear future user: Do not name a Page class the same like a subpackage of the package in which the class resides (or the other way round). This will lead to pages in subpackages (i.e. subpages) not loading. Read again the topic on activation context in the docs and you will understand why ;-) Kind regards and further enjoy the use of Tapestry, nillehammer Am Dienstag, 12. Februar 2008 01:01 schrieb Howard Lewis Ship: > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
