Howard, thanks for commenting! I will add my comments to the comments this evening.
Geoff On 12/1/05, Apache Wiki <[EMAIL PROTECTED]> wrote: > 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] > > -- The Spindle guy. http://spindle.sf.net Get help with Spindle: http://lists.sourceforge.net/mailman/listinfo/spindle-user Announcement Feed: http://www.jroller.com/rss/glongman?catname=/Announcements Feature Updates: http://spindle.sf.net/updates --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
