On 2/28/06, Howard Lewis Ship <[EMAIL PROTECTED]> wrote:
> 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?)
You need to describe this class loading mechanism better. Am I right
to say that unlike T4 you want to move the enchancement process inside
a custom classloader?
(The following is my thought process based on the assumption that the
answer to my last question is yes.).
So you want to configure this classloader to do magic on a finite set
of packages and ignore (do less processing like enhancement - work
like normal loader) on any class outside of those packages.
There could be that case that developer accidentally places a class
that should be enhanced outside the 'package space' used by the
loader. Would be nice if the loader could detect/warn on this.
So, each namespace contributes a list of packages that loader should
add to it's internal package space. I think the package sets
contibuted by two namespaces can and quite often will ovelap so T5
should not use this as a mechanism to infer the membership of any
page/component in a particular namespace.
Like you wrote, the loader package space idea would address a
scalability concern and it would be used in combination with
annotations. If the class itself can id it's namespace we are still
ok.
So how do we define the package space that a namespace contributes to
the classloader?
1) package by package via Daniel's suggestion (package level annotations)
BTW this mechanism is unaware of namespaces at all which might be attractive.
Pros: Gives developers complete control over what's in and what's out.
Cons: Could be burdonsome to have to add a source file to every package.
The meta package list is already a mechanism for finding
packages and there could be a mismatch between the meta list and the
actual packages that are annotated.
2) Use the meta scheme currently used in T4. a pacakge fragment in the
meta specifies that a package and all of it's subpackages should be
considered by the loader.
Pros: define all in one place, the namespace specification
Cons: Users have less 'control' of what's in and what's out. One can't
exclude one subpackage or another.
Since the meta package list isn't going away anyways (I think), I
would say stick with it.
Does all that align with your thinking?
BTW I guess there will need to be a @Mixin annotation?
>
> 2) I would love a solution that was case insensitive (!) Perhaps the
> page alias could accomplish this.
If you mean can the developer chose to refer to a page/componet by a
name that is (possible) in a different case than the class name, then
yes.
If the "class is the component" I would suggest that aliasing be the
only way to accomplish this. Class naming is case sensitive and I
think that any magic that tapestry would do to relate 'myfoo' as
refering to myfoo.class or MyFoo.class would cause grief. What if
there were two classes in the same package, myfoo.class and
MyFoo.class?
Besides, I think I'm just against the idea in general. Probably due to
the annoying aspects of the case insenitivity of the windows
filesystem!
Geoff
>
> 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]
>
>
--
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]
