[ http://issues.apache.org/jira/browse/TAPESTRY-724?page=comments#action_12359117 ]
Geoff Longman 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. ok. a valid solution. >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. What about if someone does this? <page name="P1" specification-path="pages/Page"/> <page name="P2" specification-path="pages/Page"/> Going to cause problems! The easy solution would be to ban the above outright but I think doing this would decrease the usefulness of specifying pages directly in the namespace xml. Follows is a case in T3 where we found the ability to map two names to one spec useful... We actually have this in our T3 application right now. We have a page that is show that has displays links ans styles them to look ike tabs. These tabs appear on the top of every page and thier behaviour is dependant on what page is displaying them. Call the tabs "Manage" and "Create". But, there are many pages that would are considered "Manage" pages and other that are considered "Create" pages. In the case of the "Create" there are 3 pages (a 3 step wizard). If a "Manage" page is rendered, the Manage tab appears to be selected. The opposite applies for "Create" pages. There is also a 'home' page for each tab. Clicking the "Create" will always take the user to "CreateActivityStep1". We have a component that renders the tabs. The component knows which pages (a map of page names) fall under each tab and also which is the 'home' page for each tab. When the Tab component renders, it chooses css for the tabs based on the name of the page it being rendered. A create page would cause the tab component to render the "Create" tab as selected and not clickable while the "Manage" tab is smaller and clickable. Long story short we ran into a case where one page needed to be shown in both tabs. Since the component was keying off of the page name we aliased the shared page with two names, one each for the Manage and one for the Create cases. This was the easiest solution ( literally a 5 minute solution) as the page behaves exactly the same in both cases. <page name="ConfirmActivitySaveManage" specification-path="pages/ConfirmActivitySave.page"/> <page name="ConfirmActivitySaveCreate" specification-path="pages/ConfirmActivitySave.page"/> So what would happen in this case? Our class is called ConfirmActivitySave.java and Tapestry would never find it. Say we were managing, Tapestry would look for and fail to find ConfirmActivityManage.class. And **Tapestry would never ever look for ConfirmActivitySaveCreate"** since it chose BasePage when ConfirmActivityManage.class. Even worse, our page class is niether of the name options. So I rename the class to ConfirmActivitySaveManage.java - this works only if the user visits a Manage page first and will fail if they visit the create tab first. It's a contrived example, in the xml. I like the xml and don't ever see myself making a totally xml-less page.in this case I would continue to specify the classname >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. The future is the future. Tapestry 4 is what's going out the door soon. >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. You say that but when I look at the code, the spec is still resolved first. Every time. >The solution is to follow Tapestry's rules for naming and not use the <page> >element in the application specification. But it's still allowed and Spindle must be able to handle it. Spindle has to handle **every possible legal case** or it will produce garbage. >I don't want to introduce even more special cases that will cause even more of >a headache to support in the future. Too late man. There are so many special cases in there now. Tools don't have the luxury of picking and choosing what rules to abide by. >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. In all versions of Tapestry till now, the specification has been the identity object. Tap 3 fudged in a special case for specless pages but even then a fake specification was created to conform. Even now the specification is resolved BEFORE the class lookup occurs and fake specifications are still created as needed. If it walks like a duck and quacks like a duck... But, the real problem, the killer problem , is if a specification file can have more than one class. Especially now with annotations contributing how does one "validate" a specification file if in some cases the annotations come from here and in some cases they come from there? Makes for a huge confusing pile of error markers on one file. Also, since the annotations in a page class can come from many other classes (superclasses, interfaces) I'm looking ahead to the same kind of problem when validating the annotations themselves. markers in the java files will have to be restricted to syntax errors as context specific errors would pile up again if say an interface was used in many pages. There needs to be one place where the context specific errors for A PAGE can pile up. The spec seems to be the logical place. The template is no good 'cuz there are potentially many templates for one page (internationalization). The case of a specless page is a case I can work around. >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. Let me turn that around. If page specs can be associated with more than one class (whatever the name of the class is based on) there is possibly no to build a tool like Spindle that can reasonable handle it and still be user friendly. Ever wonder why there is no javascript IDE with the same capabiltiies of an Eclipse or IDEA? Too hard as so much depends on the runtime state. Tapestry is tripping close to that edge. >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. Again I don't care if the classname aligns with the spec name. It has been an unwritten convention for a darn long time that the classname most often does align. > 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]
