You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Geoff Longman <gl...@gmail.com> on 2005/10/12 05:52:04 UTC
Wierd class discovery behaviour
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
Re: Wierd class discovery behaviour
Posted by Geoff Longman <gl...@gmail.com>.
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 <gl...@gmail.com> 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 <gl...@gmail.com> 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 <gl...@gmail.com> 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 <hl...@gmail.com> 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 <gl...@gmail.com> 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 <gl...@gmail.com> 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: tapestry-dev-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > 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: tapestry-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > 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: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Wierd class discovery behaviour
Posted by Geoff Longman <gl...@gmail.com>.
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 <gl...@gmail.com> 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 <gl...@gmail.com> 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 <hl...@gmail.com> 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 <gl...@gmail.com> 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 <gl...@gmail.com> 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: tapestry-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > 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: tapestry-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> > >
> > >
> >
> >
> > --
> > 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: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Wierd class discovery behaviour
Posted by Geoff Longman <gl...@gmail.com>.
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 <gl...@gmail.com> 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 <hl...@gmail.com> 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 <gl...@gmail.com> 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 <gl...@gmail.com> 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: tapestry-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> > >
> > >
> >
> >
> > --
> > 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: tapestry-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >
> >
>
>
> --
> 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: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Wierd class discovery behaviour
Posted by Geoff Longman <gl...@gmail.com>.
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 <hl...@gmail.com> 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 <gl...@gmail.com> 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 <gl...@gmail.com> 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: tapestry-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >
> >
>
>
> --
> 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: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
--
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: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Wierd class discovery behaviour
Posted by Howard Lewis Ship <hl...@gmail.com>.
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 <gl...@gmail.com> 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 <gl...@gmail.com> 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: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
--
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: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Wierd class discovery behaviour
Posted by Geoff Longman <gl...@gmail.com>.
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 <gl...@gmail.com> 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: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org