[ http://issues.apache.org/jira/browse/TAPESTRY-724?page=comments#action_12359120 ]
Geoff Longman commented on TAPESTRY-724: ---------------------------------------- I'm thinking hard about how Spindle will work with a static project. Here is the Spindle problem in capsule format. Specless pages - Spindle has no notion of the "name" used to access the page. Pages have templates, I can find those easily. If I can work back from the template to the class/spec I'm laughing. How to do this? Specless page templates are relative to the context root, and with the new exclusion of WEB-INF, I can eliminate templates under WEB-INF. yay! So, any template in the context is a potential specless page. Tapestry puts the fake spec relative to the namespace location (no path), I can duplicate this. I have the path of the template, can I infer that the classname will be similar to that path? ie: context:/pages/Foo.html implies <something>.pages.Foo is the class? Specful pages - I can find the Spec - if the spec declares the class, fine. If not, acrobatics ensue - this is the crux of this bug report. Given (and this is all Spindle has to go with!): /WEB-INF/pages/Foo.page Assuming that Foo.page is not declared in the namespace file I think it's realistic that the *only way* someone can reference the page is "pages/Foo". and thus the class will be <something>.pages.Foo Is this true? Now the scary part: <page name="Foo" specification-path="pages/Foo.page"/> <page name="Moo" specification-path="pages/Foo.page/> If Foo.page declares the class - fine, no problem. If not, I'm stuck. And this is where Tapestry will break at runtime in varied an interesting ways depending on what the user decides to name the class. Perhaps the above should be an error? This is another special case and a hard thing I think for Tapestry to capture at runtime. Recall the above *is ok* if Foo.page declares its class explicity. But, I'm thinking that Spindle *can* capture this case and mark an error. So the question is: are you willing to let this "unfortunate ambiguity" remain in the Tapestry codebase? I have a nugget of an idea on how Tapestry can capture the baddie situation and throw an error.. More to follow. > 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]
