Re: [Hint] Pages in subpackages not loaded, if page and subpackage have the same name
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.
Re: [Hint] Pages in subpackages not loaded, if page and subpackage have the same name
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]
Re: [Hint] Pages in subpackages not loaded, if page and subpackage have the same name
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]
Re: [Hint] Pages in subpackages not loaded, if page and subpackage have the same name
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]
Re: [Hint] Pages in subpackages not loaded, if page and subpackage have the same name
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]
Re: [Hint] Pages in subpackages not loaded, if page and subpackage have the same name
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]
[Hint] Pages in subpackages not loaded, if page and subpackage have the same name
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]
