[ http://issues.apache.org/jira/browse/TAPESTRY-724?page=comments#action_12359074 ]
Howard M. Lewis Ship commented on TAPESTRY-724: ----------------------------------------------- So far, I've added tests to ensure that your case #3 is rejected out of hand. That is, page names that start with "/WEB-INF/" or "WEB-INF/" (case insensitive) are rejected out of hand. Example error message: Page name '/WEB-Inf/BadName' is not valid, as it directly references a file stored in the WEB-INF folder. I still see the only ambiguity is the page name vs. the specification path. You have "Page" mapped to "MyPage.page". Done this way, Tapestry doesn't locate the Java class "com.myfoo.MyPage" since it looks for "com.myfoo.Page" instead. I'm having trouble seeing why this is a problem. The Java class is derived from the page name not the specification path. I think this is correct and is the path I prefer in the future, where the page class is always resolved from the page name BEFORE the page specification is located and read. What we have here are two distrinct pages, "Page" and "MyPage", that share a single page specification, but are distinct from Tapestry's point of view. The key thing is that the page name drives the process, everything else is subservient to it. Its unfortunate that the current evolution of the framework yields these kinds of ambiguities. The solution is to follow Tapestry's rules for naming and not use the <page> element in the application specification. I don't want to introduce even more special cases that will cause even more of a headache to support in the future. At the core of this is the identity of the page; you are trying to make the identity be the page specification, and see ambiguities that you can reach that page specification with multiple names. I see the page name as the real identity, and the fact that different pages can share the same page specification to be an unfortunate ambiguity. Thus, from your point of view, we should always be looking for a Java class whose name matches the page spec, i.e., MyPage. From my point of view, the developer is in error to expect "Page" and "MyPage" to be the same page and use the same class. > Tapestry may, in some cases, look for a page class in the wrong package > ----------------------------------------------------------------------- > > Key: TAPESTRY-724 > URL: http://issues.apache.org/jira/browse/TAPESTRY-724 > Project: Tapestry > Type: Bug > Components: Framework > Versions: 4.0 > Reporter: Geoff Longman > Assignee: Howard M. Lewis Ship > Priority: Critical > Attachments: test.zip > > I've been trying to come up with a patch but work has been getting crazy and > I have been ill for days now. > A detailed description of the problem (and apossible solution) is to be found > here: > http://wiki.apache.org/jakarta-tapestry/GeoffLongmanSandbox > In a nutshell, if a user references a Tapestry page whose class must be found > from a given list of packages it may be the case that way they have > referenced (by name) may mislead the ComponentClassProvider to look in the > wrong package. If that happens, the class is not found and (in most cases) > BasePage is assigned as the page class. Often this will break the application > if the page depends on a class other than BasePage. Depending on how the app > is set up there could be 3 or more legal ways to reference a page by name > (path parts) but only one way will result in the right page class being > located. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
