A few comments:
1) The class loading mechanism will work best, I think, if there are a
a finite set of packages that can contain pages/components and mixins.
Using an annotation is part of the solution, but may not be scalable
(how do you know which classes need to be loaded and enhanced?)
2) I would love a solution that was case insensitive (!) Perhaps the
page alias could accomplish this.
On 2/28/06, Geoff Longman <[EMAIL PROTECTED]> wrote:
> Ok. I'm getting a handle on mixins and the render queue - not
> perfectly yet but that's not suprising this early in the process. I
> look forward to continue the discussion on the other thread.
>
> But, to selfishly steer the debate back to issues that affect me now...
>
> Any more reaction to the namespace issues we have now and my suggested
> solution?
>
> To recap:
>
> if "the class is the component" (allowing for the edge cases already
> outlined) the FQN of the class is the global name of the component.
>
> The exercise now becomes one that:
>
> 1. Empowers developers to use simpler, shorter names to refer to those
> pages and components (or mixins).
> 2. Ensures that the negative affects of "Namespace Boundary Crossing"
> are eliminated. (IMHO there are no positive aspects!)
>
> I think that the mechaisms for 1 & 2 should not overlap. in other
> words things like
>
> org.apache.tapestry.page-class-packages
>
> should play a role only in 'devising' shorter names (1) and play no
> role in 'locating' a page or component in a particular namespace (2)
>
> and
>
> whatever the solution to 2 is play no role in short names (1)
>
> My proposal for #1 is that the optional <page>, <component> tags be
> removed and replaced by optional <page-alias> and <component-alias>
> tags. org.apache.tapestry.page-class-packages remains as it is today,
> a scheme to map a short name to an FQN.
>
> For #2 I would love to see @PageType and @ComponentType annotations
> where a namespace attribute is included in both. Optional for
> pages/component in the application namespace and required for those in
> libraries. Also, <library-specification> tags have a mandatory name
> attribute.
>
> A developer 'mounts' a library. The details of what the mount is
> isn't crucial. the important part is that user is defining thier own
> "name" for the library - a happy side effect of which is that this
> mounting would be used to disambiguate two libraries sharing the same
> name.
>
> Tapestry can easily map the "mount" name to the librarie's declared
> name and then check to see if a reference is legal by comparing the
> declared name to the @ComponentType{ns="contrib"} name (contrib in
> that example).
>
> C'est tout.
>
> 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: [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]
