Dear Wiki user, You have subscribed to a wiki page or wiki category on "Jakarta-tapestry Wiki" for change notification.
The following page has been changed by HowardLewisShip: http://wiki.apache.org/jakarta-tapestry/GeoffLongmanSandbox ------------------------------------------------------------------------------ In fact it's worse than this. There could be the case where an app had two links, one in a form (not an HTML form!) that would cause Tapestry to find the correct class and one that would not. When this is possible then the stability of the application is suspect because all depends on whether the first user clicked the right link. If the first click by the first user was on the bad link, the whole app is broken until the servlet container is restarted. Currently the [http://jakarta.apache.org/tapestry/tapestry/apidocs/org/apache/tapestry/pageload/ComponentClassProvider.html ComponentClassProvider] uses a Hivemind chain to search for the page class. Passed into this chain is an instance of [http://jakarta.apache.org/tapestry/tapestry/apidocs/org/apache/tapestry/pageload/ComponentClassProvider.html ComponentClassProviderContext] which contains: - *the page name + * the page name - *the !INamespace for the page + * the INamespace for the page - *the page specification + * the page specification - One member of the chain, [http://jakarta.apache.org/tapestry/tapestry/apidocs/org/apache/tapestry/pageload/NamespaceClassSearchComponentClassProvider.html NamespaceClassSearchComponentClassProvider], gets a list of packages {{{say com.myfoo}}} by checking a property in the Namespace and then checks each package for a class with a fully qualified name of the package with the page name appended. If the !NamespaceClassSearchComponentClassProvider does not locate a class it falls to other members of the chain and in most cases the resulting class would be {{{org.apache.tapestry.html.BasePage}}}. + One member of the chain, [http://jakarta.apache.org/tapestry/tapestry/apidocs/org/apache/tapestry/pageload/NamespaceClassSearchComponentClassProvider.html NamespaceClassSearchComponentClassProvider], gets a list of packages, say {{{com.myfoo}}}, by checking a property in the Namespace and then checks each package for a class with a fully qualified name of the package with the page name appended. If the !NamespaceClassSearchComponentClassProvider does not locate a class it falls to other members of the chain and in most cases the resulting class would be {{{org.apache.tapestry.html.BasePage}}}. The problem arises because the page name may be a path like{{{ pages/MyPage @@ -53, +53 @@ com.myfoo.WEB-INF.pages.MyPage }}} + HowardLewisShip: The third option is something I've never considered and would consider banning outright. Also, I believe that page "Page" and page "pages/MyPage" are *distinct* pages, because they have distinct page names ("Page" vs. "pages/MyPage"). The expectation is that page "Page" will be class "com.myfoo.Page" and page "pages/MyPage" will be class "com.myfoo.pages.MyPage". + - In all cases but the second, the page class Tapestry is searching for is not found and usually !BasePage ends up being used. And if {{{com.myfoo.pages.MyPage}}} has some properties that are refenced by, say, an {{{ognl}}} expression in the template, the page will break. + In all cases but the second, the page class Tapestry is searching for is not found and usually !BasePage ends up being used. And if {{{com.myfoo.pages.MyPage}}} has some properties that are refenced by an OGNL expression in the template, the page will break. I think this problem also, in some cases, affects template lookup, but I have not delved into that. + === The Fix === It seems to me that the way this can be fixed so that Tapestry always looks for and finds {{{com.myfoo.pages.MyPage}}} is to do a bit more processing on the name passed in before handing things off to the !PageClassProvider. In every case above, Tapestry sucessfully locates the specification {{{/WEB-INF/pages/MyPage.page}}}. I think the fix would be to examine the path part of the page name and lop off the leading parts that would cause the class lookup to fail. @@ -64, +67 @@ *Compare with {{{/WEB-INF/servletname}}} , if that is a prefix, lop it off and __STOP__. *Compare with {{{/WEB-INF}}}, if that is a prefix, lop it off and __STOP__. *If the above didn't result in a lopping, then the path is good. + + HowardLewisShip: Still digesting this. There would appear to be a special case. That is{{{ <span jwcid="@PageLink" page="Page"/> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
