Almost all the tests pass even with the changes I made. The ones that are failing are in TestPageSpecificationResolver because, of course I changed things in that file.
I've spent the better part of the last two hours trying to put the tests in sync with the changes I made but easymock is doing things that are strange to me, I'm tired and I didn't get any Spindle work done today so I'm giving up for now. Geoff A question, how many tests are there? I ran 1459 in 138 seconds. On 10/14/05, Geoff Longman <[EMAIL PROTECTED]> wrote: > 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 > -- 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]
