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 2006/02/19 21:13:42 UTC

Interesting Observation

Did you know that the namespaces for Framework and Contrib overlap?

I'm writing some code to detect when namespaces (based on the location
of the spec file) overlap and as a lark I added a test case that
checks if Framework and Contrib clash. They do.

Of course Framework is "special" and you couldn't exploit the overlap like this:

@framework:contrib/components/Choose

and Contrib.library is a package below Framework. You can't refer to a
framework component from contrib unless this was legal:

@contrib:../form/Button [General Q] illegal in classpath? - what about
in the context?

So I guess it's no big deal. But an interesting example of the
boundary crossing stuff I've been blathering about lately.

Note though that user libraries do not have the special status of
Framework and thus no protection from strange behaviour based on name
choice.

ahh, but the following are both legal even though the inspector
library is 'private' to Contrib.

@contrib:inspector/DumpObject
@contrib:DumpObject

In that case no immedaite ill effects would be observed as both
libraries refer to the same .jwc file and the meta's for
'org.apache.tapestry.component-class-packages' are the same in both
Contrib.libary and Inspector.library. ie:

  <meta key="org.apache.tapestry.component-class-packages"
value="org.apache.tapestry.contrib.components"/>

I think this is a very unusual case though as I've not seen two
libraries declare the same component this way.

These are also legal and serve only to expose components/pages  in
Inspector that are not for public use:

@contrib:inspector/ShowProperties
@contrib:inspector/ShowDescription
@contrib:inspector/ShowEngine

<span jwcid="@PageLink" page="contrib:inspector/Inspector"/>

etc.

Geoff

--
The Spindle guy.          http://spindle.sf.net
Get help with Spindle:   
http://lists.sourceforge.net/mailman/listinfo/spindle-user
Blog:                     http://jroller.com/page/glongman
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: Interesting Observation

Posted by Geoff Longman <gl...@gmail.com>.
I've been experimenting.

As expected these don't work:

<span jwcid="@PageLink" page="framework:contrib/inspector/Inspector"/>

and

<span jwcid="@PageLink" page="contrib/inspector/Inspector"/>

I know the first wouldn't work as "framework" is special and not can't
be referred to in this way.

I was worried about the second as one of the page lookup rules is
"check the framework" and contrib/inspector/Inspector is a valid path
relative to Framework.library.

I see now how the framework is protected from this, again by it's
special status.

I was able to do this though:

<span jwcid="@PageLink" page="contrib:inspector/Inspector"/>

Tapestry finds/instantiates the page ok but subsequently breaks as
Inspector's implementation won't work if the page is referenced in
this way.

And I was able to show that references to the components in Inspector
can be made  **without** adding

<library id="inspector"
        specification-path="/org/apache/tapestry/contrib/inspector/Inspector.library"/>

to the application file. As long as Contrib is in there:

@contrib:inspector/ShowEngine - is legal

And now I have all the interesting engine 'stuff' in my page.

Geoff









On 2/19/06, Geoff Longman <gl...@gmail.com> wrote:
> Did you know that the namespaces for Framework and Contrib overlap?
>
> I'm writing some code to detect when namespaces (based on the location
> of the spec file) overlap and as a lark I added a test case that
> checks if Framework and Contrib clash. They do.
>
> Of course Framework is "special" and you couldn't exploit the overlap like this:
>
> @framework:contrib/components/Choose
>
> and Contrib.library is a package below Framework. You can't refer to a
> framework component from contrib unless this was legal:
>
> @contrib:../form/Button [General Q] illegal in classpath? - what about
> in the context?
>
> So I guess it's no big deal. But an interesting example of the
> boundary crossing stuff I've been blathering about lately.
>
> Note though that user libraries do not have the special status of
> Framework and thus no protection from strange behaviour based on name
> choice.
>
> ahh, but the following are both legal even though the inspector
> library is 'private' to Contrib.
>
> @contrib:inspector/DumpObject
> @contrib:DumpObject
>
> In that case no immedaite ill effects would be observed as both
> libraries refer to the same .jwc file and the meta's for
> 'org.apache.tapestry.component-class-packages' are the same in both
> Contrib.libary and Inspector.library. ie:
>
>   <meta key="org.apache.tapestry.component-class-packages"
> value="org.apache.tapestry.contrib.components"/>
>
> I think this is a very unusual case though as I've not seen two
> libraries declare the same component this way.
>
> These are also legal and serve only to expose components/pages  in
> Inspector that are not for public use:
>
> @contrib:inspector/ShowProperties
> @contrib:inspector/ShowDescription
> @contrib:inspector/ShowEngine
>
> <span jwcid="@PageLink" page="contrib:inspector/Inspector"/>
>
> etc.
>
> Geoff
>
> --
> The Spindle guy.          http://spindle.sf.net
> Get help with Spindle:
> http://lists.sourceforge.net/mailman/listinfo/spindle-user
> Blog:                     http://jroller.com/page/glongman
> 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
Blog:                     http://jroller.com/page/glongman
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