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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
