Have been doing some investigation. In my copy of the code I went ahead and moved the page class lookup chain into PageSpecificationResolverImpl and had made some interesting observations.
Note that in the project I fixed some typos in the project I sent earlier and renamed the page class from com.myfoo.Home to com.myfoo.MyHome to align the classname with the spec name (MyHome.page). the following now all work. yay! <span jwcid="@PageLink" page="Home">Jump</span> <span jwcid="@PageLink" page="WEB-INF/MyHome">Jump</span> <span jwcid="@PageLink" page="MyHome">Jump</span> And with specification caching in the SpecificationSource (which has been there forever of course) it's all very efficient. Three page names are installed in the namespace but the same spec is associated each time. I curious though, ComponentConstructorFactoryImpl caches enhanced classed in Map using a specification as the key. Why not cache using the fully qualified classname as the key? Is there a case where one would need to enhance a class more than once? Geoff On 10/13/05, Geoff Longman <[EMAIL PROTECTED]> wrote: > I think the arguments I've given have missed one point. > > If I reference a specless page in T3, it looks in the context root for > the template. I guess that in T4, referencing specless > "com/myfoo/MyPage" should result in the template being loaded from > context:/com/myfoo/MyPage.html? > > This is doable with the changes I have described, with one more change :-) > > Currently when a standin page specification is created it is given the > location context:/pageName.page > > and the template pageName.html is resolved relative to that location. > > The change I would suggest is that if the page name has a path element > then set the resource location of the standin to reflect the path > part. > > So "com/myfoo/MyPage"'s standin would have a specification location of > context:com/myfoo/MyPage.page > > and the template would be found at context:/com/myfoo/MyPage.html > > Geoff > > > > > > > On 10/13/05, Geoff Longman <[EMAIL PROTECTED]> wrote: > > Hmm, page name --> page class --> specification. > > > > This is contrary to the way Tapestry has worked since 3.0 and I'm not > > sure this could be achieved and still maintain any notion of backwards > > compatibility. The 3.0 mechanism looks for specs first in various > > places based on the name. People have been placing a spec in one of > > those locations and using the spec name as the page name. Not the only > > way to do it of course but a common method. > > > > Isn't the underlying goal to able to handle pages that do not have > > specs? Tapestry 3.0 was already halfway there so the goal is really to > > *improve* how Tapestry handles pages that do not have specs. And that > > improvement is to be able to infer a page class in these cases. An > > added bonus is that we would like to allow pages that *do* have specs > > to use the same mechanism to infer thier page classes. > > > > T4 still looks for the spec first in all cases and currently the page > > class is not inferred until the page instance is needed. > > > > page name->page spec --------*PageLoader*------page class (maybe > > inferred)----->page instance > > > > Since standin specs are created as required before page instances are > > created I think it makes sense to do this: > > > > page name->page spec->page class(maybe > > inferred)--------*PageLoader*------>page instance > > > > with the inference based on the name of the spec (which is the page > > name if a stand-in was created). > > > > I'm thinking that this will achieve the goal, maintain backwards > > compatibility, and altogether avoid the nasty problem I first > > described. > > > > The last argument I can make is: Is the behaviour I discovered an > > intended feature of T4? If not then I think it's a bug. > > > > Geoff > > > > On 10/12/05, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > > > Have to think about it; basically, I'm tring to shift Tapestry towards > > > the following: page name --> page class --> specification; right now > > > its backwards, page name --> specification --> page class. I can't > > > tell if your suggestion is more correct or not; sounds like it might > > > be. > > > > > > On 10/12/05, Geoff Longman <[EMAIL PROTECTED]> wrote: > > > > ok. here's a suggestion. why not move the page classname lookup into > > > > the PageSpecificationResolverImpl? Use the same lookup chain but in a > > > > different place. > > > > > > > > I think this would handle all the cases. > > > > > > > > Pages: > > > > > > > > resolver finds a page spec and does the resolve on the name of the > > > > spec file. I don't think this is unreasonable. All the pages I've ever > > > > built had classes based on the name of the .page file and not on the > > > > name used to reference the page at runtime. > > > > > > > > resolver finds a specless page - currently the > > > > PageSpecificationResolver creates a stand in spec with a location > > > > relative to it's namespace with a name of _simpleName + ".page". So > > > > you could still do the classname resolution on the simple name. > > > > > > > > Plus, now that I've taken a closer look at the code for > > > > ComponentSpecificationResolverImpl I see that it is doing exactly what > > > > I have described above (but without a chain). > > > > > > > > IMHO leaving things the way they are is leaving a bit of 'magic' in > > > > the system that is of questionable value to end users. More likely > > > > it'll be a cause of frustration due to a lack of consistency. Perhaps > > > > a rare cause of frustration but a cause none the less. > > > > > > > > thoughts? > > > > > > > > Geoff > > > > > > > > On 10/11/05, Geoff Longman <[EMAIL PROTECTED]> wrote: > > > > > I'm trying to get a handle on how the page class provider chain works. > > > > > > > > > > attached is a 3k zip of a little project that displays a problem I > > > > > found with the way classes are discovered. (If the zip does not get > > > > > through email me directly and I'll pass it along). > > > > > > > > > > The classname used for discovery is the page name passed into the > > > > > PageLoader . In the example I'm referencing the 'home' page in 3 ways, > > > > > only one of which comes up with the right page class. > > > > > > > > > > In capsule... > > > > > > > > > > in application file.. > > > > > > > > > > <meta key="org.apache.tapestry.page-class-packages" > > > > > value="com.myfoo"/> > > > > > <page name="Home" specification-path="WEB-INF/MyHome.page" /> > > > > > > > > > > there exists a class com.myfoo.Home, which has a property foo. > > > > > MyHome.html references the foo property. > > > > > > > > > > referencing the page as "Home" works as the page name "Home" is used > > > > > during class discovery. > > > > > > > > > > but, referencing the page as "WEB-INF/MyHome" or "MyHome" does not > > > > > work as there are no classes named 'com.myfoo.WEB-INF/MyHome' or > > > > > 'com.myfoo.MyHome'. BasePage is used and the expression ognl:foo fails > > > > > in the template. > > > > > > > > > > The Exception page as usual is thorough but not really helpful in > > > > > tracking down this problem unless you know what you are looking for. > > > > > > > > > > Perhaps it would be better to base the class discovery on the name of > > > > > the Specification file? But what happens if there is no specification > > > > > file? > > > > > > > > > > Geoff > > > > > > > > > > -- > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > 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] > > > > > > > > > > > > > > > > > -- > > > Howard M. Lewis Ship > > > Independent J2EE / Open-Source Java Consultant > > > Creator, Jakarta Tapestry > > > Creator, Jakarta HiveMind > > > > > > Professional Tapestry training, mentoring, support > > > and project work. http://howardlewisship.com > > > > > > --------------------------------------------------------------------- > > > 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 > > > > > -- > 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 > -- 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]
