You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Hugo Palma <hu...@gmail.com> on 2007/01/09 18:34:22 UTC
T5: Component libraries
How is support for component libraries being implemented in T5 ? I'm
guessing the base component classes package is configured in the jar
file manifest, is that it ?
Cheers,
Hugo
Re: T5: Component libraries
Posted by Howard Lewis Ship <hl...@gmail.com>.
Yep, I'm starting to transition from Eclipse to IDEA. Lots to relearn. I'm
looking forward to finding out if IDEA really is that much better!
On 5/10/07, Hugo Palma <hu...@gmail.com> wrote:
>
> Cool, all i needed to know.
>
> I'm all for simplification, you wouldn't believe how much simpler it has
> been to implement all the component path resolution stuff in TapIDEA for
> T5
> than it was when i started with Spindle for T4. Everything is so much
> simpler and more straight forward....I'm just finishing up the 0.2 release
> which will have some cool features already, hope you can test it too :o)
>
>
>
> On 5/10/07, Howard Lewis Ship <hl...@gmail.com> wrote:
> >
> > Implemented but not documented. I expect to add support for
> > per-application
> > and per-library message catalogs and then document the whole thing.
> >
> > Again, I'd like to re-iterate something: the very dogmatic, structured
> > approach in Tapestry 4 existed to handle the cases of really unfortunate
> > naming conflicts. To my knowledge, none of these naming conflicts ever
> > occured in practice. That's why a simplification for T5 is reasonable.
> > We've
> > had a couple of years of experiment to balance the cost (more
> complexity,
> > to
> > the point that Spindle never did catch up) vs. avoiding otherwise
> > unavoidable naming conflicts (that turned out to be phantoms).
> >
> > On 5/9/07, Hugo Palma <hu...@gmail.com> wrote:
> > >
> > > Is this already implemented in the 5.0.4 release ? I can't find
> anything
> > > on the docs....
> > >
> > > Howard Lewis Ship wrote:
> > > > I think many, especially Geoff Longman, would agree that Tapestry 4
> > > > librarys/namespaces are a bit overengineered, and contain some
> > unwanted
> > > > ambiguities.
> > > >
> > > > Every T5 library will need to include a Tapestry IOC module.
> > > >
> > > > The module will make a contribution to the
> > > > tapestry.ComponentClassResolverconfiguration. Example:
> > > >
> > > > public static void
> > > > contributeComponentClassResolver(Configuration<LibraryMapping>
> > > > configuration)
> > > > {
> > > > configuration.add(new LibraryMapping("core", "
> > > > org.apache.tapestry.corelib"));
> > > > }
> > > >
> > > > This maps pages, components and mixins under path "core/" to be
> inside
> > > > the
> > > > .corelib package. "core" also has a privileged function, in that
> when
> > a
> > > > name is not found elsewhere, core is searched. In this way,
> comopnents
> > > > inside core are available to the application without having to say
> > > > "core/TextField".
> > > >
> > > > Say you created a nifty library:
> > > >
> > > > @Contribute("tapestry.ComponentClassResolver")
> > > > public static void
> > > > contributeComponentClassResolver(Configuration<LibraryMapping>
> > > > configuration)
> > > > {
> > > > configuration.add(new LibraryMapping("nifty",
> > > > "com.example.niftylib
> > > > "));
> > > > }
> > > >
> > > > This does a few things, including setting up the packages below
> > niftylib
> > > > (pages, components, mixins and base) to be loaded and reloaded by
> the
> > > > enhancing class loader.
> > > >
> > > > You could then reference components in the library as
> > t:id="nifty/Foo".
> > > > This is necessary both in the application, and inside other
> > > > pages/components
> > > > inside the "nifty" library.
> > > >
> > > > Unlike Tapestry 4, there aren't confusing and ambiguous nested
> > > > hierarchys of
> > > > namespaces. Library authors will need to be sensible about providing
> a
> > > > reasonably unique path to keep from creating conflicts.
> > > >
> > > > The folder name ("nifty") should not start or end with a slash, but
> > may
> > > > contain one. This may help with ensuring non-conflicting names.
> > > >
> > > > Tapestry may, soon, assume that the folder name is lower case. I'm
> > > > looking
> > > > to ensure that at least the path portion of request URLs is case
> > > > insensitive.
> > > >
> > > > On 1/9/07, Hugo Palma <hu...@gmail.com> wrote:
> > > >>
> > > >> How is support for component libraries being implemented in T5 ?
> I'm
> > > >> guessing the base component classes package is configured in the
> jar
> > > >> file manifest, is that it ?
> > > >>
> > > >> Cheers,
> > > >>
> > > >> Hugo
> > > >>
> > > >>
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > Howard M. Lewis Ship
> > TWD Consulting, Inc.
> > Independent J2EE / Open-Source Java Consultant
> > Creator and PMC Chair, Apache Tapestry
> > Creator, Apache HiveMind
> >
> > Professional Tapestry training, mentoring, support
> > and project work. http://howardlewisship.com
> >
>
--
Howard M. Lewis Ship
TWD Consulting, Inc.
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Apache HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
Re: T5: Component libraries
Posted by Hugo Palma <hu...@gmail.com>.
Cool, all i needed to know.
I'm all for simplification, you wouldn't believe how much simpler it has
been to implement all the component path resolution stuff in TapIDEA for T5
than it was when i started with Spindle for T4. Everything is so much
simpler and more straight forward....I'm just finishing up the 0.2 release
which will have some cool features already, hope you can test it too :o)
On 5/10/07, Howard Lewis Ship <hl...@gmail.com> wrote:
>
> Implemented but not documented. I expect to add support for
> per-application
> and per-library message catalogs and then document the whole thing.
>
> Again, I'd like to re-iterate something: the very dogmatic, structured
> approach in Tapestry 4 existed to handle the cases of really unfortunate
> naming conflicts. To my knowledge, none of these naming conflicts ever
> occured in practice. That's why a simplification for T5 is reasonable.
> We've
> had a couple of years of experiment to balance the cost (more complexity,
> to
> the point that Spindle never did catch up) vs. avoiding otherwise
> unavoidable naming conflicts (that turned out to be phantoms).
>
> On 5/9/07, Hugo Palma <hu...@gmail.com> wrote:
> >
> > Is this already implemented in the 5.0.4 release ? I can't find anything
> > on the docs....
> >
> > Howard Lewis Ship wrote:
> > > I think many, especially Geoff Longman, would agree that Tapestry 4
> > > librarys/namespaces are a bit overengineered, and contain some
> unwanted
> > > ambiguities.
> > >
> > > Every T5 library will need to include a Tapestry IOC module.
> > >
> > > The module will make a contribution to the
> > > tapestry.ComponentClassResolverconfiguration. Example:
> > >
> > > public static void
> > > contributeComponentClassResolver(Configuration<LibraryMapping>
> > > configuration)
> > > {
> > > configuration.add(new LibraryMapping("core", "
> > > org.apache.tapestry.corelib"));
> > > }
> > >
> > > This maps pages, components and mixins under path "core/" to be inside
> > > the
> > > .corelib package. "core" also has a privileged function, in that when
> a
> > > name is not found elsewhere, core is searched. In this way, comopnents
> > > inside core are available to the application without having to say
> > > "core/TextField".
> > >
> > > Say you created a nifty library:
> > >
> > > @Contribute("tapestry.ComponentClassResolver")
> > > public static void
> > > contributeComponentClassResolver(Configuration<LibraryMapping>
> > > configuration)
> > > {
> > > configuration.add(new LibraryMapping("nifty",
> > > "com.example.niftylib
> > > "));
> > > }
> > >
> > > This does a few things, including setting up the packages below
> niftylib
> > > (pages, components, mixins and base) to be loaded and reloaded by the
> > > enhancing class loader.
> > >
> > > You could then reference components in the library as
> t:id="nifty/Foo".
> > > This is necessary both in the application, and inside other
> > > pages/components
> > > inside the "nifty" library.
> > >
> > > Unlike Tapestry 4, there aren't confusing and ambiguous nested
> > > hierarchys of
> > > namespaces. Library authors will need to be sensible about providing a
> > > reasonably unique path to keep from creating conflicts.
> > >
> > > The folder name ("nifty") should not start or end with a slash, but
> may
> > > contain one. This may help with ensuring non-conflicting names.
> > >
> > > Tapestry may, soon, assume that the folder name is lower case. I'm
> > > looking
> > > to ensure that at least the path portion of request URLs is case
> > > insensitive.
> > >
> > > On 1/9/07, Hugo Palma <hu...@gmail.com> wrote:
> > >>
> > >> How is support for component libraries being implemented in T5 ? I'm
> > >> guessing the base component classes package is configured in the jar
> > >> file manifest, is that it ?
> > >>
> > >> Cheers,
> > >>
> > >> Hugo
> > >>
> > >>
> > >
> > >
> >
>
>
>
> --
> Howard M. Lewis Ship
> TWD Consulting, Inc.
> Independent J2EE / Open-Source Java Consultant
> Creator and PMC Chair, Apache Tapestry
> Creator, Apache HiveMind
>
> Professional Tapestry training, mentoring, support
> and project work. http://howardlewisship.com
>
Re: T5: Component libraries
Posted by Howard Lewis Ship <hl...@gmail.com>.
Implemented but not documented. I expect to add support for per-application
and per-library message catalogs and then document the whole thing.
Again, I'd like to re-iterate something: the very dogmatic, structured
approach in Tapestry 4 existed to handle the cases of really unfortunate
naming conflicts. To my knowledge, none of these naming conflicts ever
occured in practice. That's why a simplification for T5 is reasonable. We've
had a couple of years of experiment to balance the cost (more complexity, to
the point that Spindle never did catch up) vs. avoiding otherwise
unavoidable naming conflicts (that turned out to be phantoms).
On 5/9/07, Hugo Palma <hu...@gmail.com> wrote:
>
> Is this already implemented in the 5.0.4 release ? I can't find anything
> on the docs....
>
> Howard Lewis Ship wrote:
> > I think many, especially Geoff Longman, would agree that Tapestry 4
> > librarys/namespaces are a bit overengineered, and contain some unwanted
> > ambiguities.
> >
> > Every T5 library will need to include a Tapestry IOC module.
> >
> > The module will make a contribution to the
> > tapestry.ComponentClassResolverconfiguration. Example:
> >
> > public static void
> > contributeComponentClassResolver(Configuration<LibraryMapping>
> > configuration)
> > {
> > configuration.add(new LibraryMapping("core", "
> > org.apache.tapestry.corelib"));
> > }
> >
> > This maps pages, components and mixins under path "core/" to be inside
> > the
> > .corelib package. "core" also has a privileged function, in that when a
> > name is not found elsewhere, core is searched. In this way, comopnents
> > inside core are available to the application without having to say
> > "core/TextField".
> >
> > Say you created a nifty library:
> >
> > @Contribute("tapestry.ComponentClassResolver")
> > public static void
> > contributeComponentClassResolver(Configuration<LibraryMapping>
> > configuration)
> > {
> > configuration.add(new LibraryMapping("nifty",
> > "com.example.niftylib
> > "));
> > }
> >
> > This does a few things, including setting up the packages below niftylib
> > (pages, components, mixins and base) to be loaded and reloaded by the
> > enhancing class loader.
> >
> > You could then reference components in the library as t:id="nifty/Foo".
> > This is necessary both in the application, and inside other
> > pages/components
> > inside the "nifty" library.
> >
> > Unlike Tapestry 4, there aren't confusing and ambiguous nested
> > hierarchys of
> > namespaces. Library authors will need to be sensible about providing a
> > reasonably unique path to keep from creating conflicts.
> >
> > The folder name ("nifty") should not start or end with a slash, but may
> > contain one. This may help with ensuring non-conflicting names.
> >
> > Tapestry may, soon, assume that the folder name is lower case. I'm
> > looking
> > to ensure that at least the path portion of request URLs is case
> > insensitive.
> >
> > On 1/9/07, Hugo Palma <hu...@gmail.com> wrote:
> >>
> >> How is support for component libraries being implemented in T5 ? I'm
> >> guessing the base component classes package is configured in the jar
> >> file manifest, is that it ?
> >>
> >> Cheers,
> >>
> >> Hugo
> >>
> >>
> >
> >
>
--
Howard M. Lewis Ship
TWD Consulting, Inc.
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Apache HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
Re: T5: Component libraries
Posted by Hugo Palma <hu...@gmail.com>.
Is this already implemented in the 5.0.4 release ? I can't find anything
on the docs....
Howard Lewis Ship wrote:
> I think many, especially Geoff Longman, would agree that Tapestry 4
> librarys/namespaces are a bit overengineered, and contain some unwanted
> ambiguities.
>
> Every T5 library will need to include a Tapestry IOC module.
>
> The module will make a contribution to the
> tapestry.ComponentClassResolverconfiguration. Example:
>
> public static void
> contributeComponentClassResolver(Configuration<LibraryMapping>
> configuration)
> {
> configuration.add(new LibraryMapping("core", "
> org.apache.tapestry.corelib"));
> }
>
> This maps pages, components and mixins under path "core/" to be inside
> the
> .corelib package. "core" also has a privileged function, in that when a
> name is not found elsewhere, core is searched. In this way, comopnents
> inside core are available to the application without having to say
> "core/TextField".
>
> Say you created a nifty library:
>
> @Contribute("tapestry.ComponentClassResolver")
> public static void
> contributeComponentClassResolver(Configuration<LibraryMapping>
> configuration)
> {
> configuration.add(new LibraryMapping("nifty",
> "com.example.niftylib
> "));
> }
>
> This does a few things, including setting up the packages below niftylib
> (pages, components, mixins and base) to be loaded and reloaded by the
> enhancing class loader.
>
> You could then reference components in the library as t:id="nifty/Foo".
> This is necessary both in the application, and inside other
> pages/components
> inside the "nifty" library.
>
> Unlike Tapestry 4, there aren't confusing and ambiguous nested
> hierarchys of
> namespaces. Library authors will need to be sensible about providing a
> reasonably unique path to keep from creating conflicts.
>
> The folder name ("nifty") should not start or end with a slash, but may
> contain one. This may help with ensuring non-conflicting names.
>
> Tapestry may, soon, assume that the folder name is lower case. I'm
> looking
> to ensure that at least the path portion of request URLs is case
> insensitive.
>
> On 1/9/07, Hugo Palma <hu...@gmail.com> wrote:
>>
>> How is support for component libraries being implemented in T5 ? I'm
>> guessing the base component classes package is configured in the jar
>> file manifest, is that it ?
>>
>> Cheers,
>>
>> Hugo
>>
>>
>
>
Re: T5: Component libraries
Posted by Hugo Palma <hu...@gmail.com>.
I agree with Kent.
This proposal reduces to near 0 chances of component path ambiguity.
As far as IDE integration is concerned, i have to say that both
solutions don't really provide an easy way for path resolution from a
static structure, but Kent's suggestion is the one that gets closer to it.
Still, both provide much simpler path resolution then T4 for IDE
plugins. The bottom line is, the more static, the better.
Kent Tong wrote:
> Hi,
>
> I think mapping from a prefix to a package (eg, core =>
> org.apache.tapestry.corelib) may not be a good solution.
> 1) What if two organizations chooses the same prefix for their respective
> library?
> 2) If I am working on a component in my app. If later I'd like to make
> it available for others to use, I certainly shouldn't be forced to
> add a prefix to all the type names. All I want is to pack it up.
>
> Instead, I'd suggest that we use the fully qualified Java class
> name as the component type name (eg, com.example.Bar). Of course
> it's too long to type it. So, we can use a mechanism similar to
> the Java import statement. That is, if component (or page)
> com.example.Foo would like to use com.example.Bar in its template,
> as they are in the same package, it can just the unqualified named:
>
> <span t:type="Bar"/>
>
> This requires that we no longer put pages into a "pages" sub-package
> and components into "components" sub-package. Instead, put them into
> the same package.
>
> If com.example.Foo would like to use a component org.abc.Baz in a
> library, it may specify the full name:
>
> <span t:type="org/abc/Bar"/>
>
> Or if Foo needs to use many such components from that library, it
> can import the org.abc package somehow. Ideally, Tapestry should
> use the import statements in Foo.java:
>
> import org.abc.Bar;
>
> class Foo {
> }
>
> To take care of the framework components, just assume the presence
> of:
>
> import org.apache.tapestry.corelib.components.*;
>
> When there is ambiguity (eg, Bar appears in two imported packages),
> then the same Java rule should apply and an explicit import is
> required.
>
> If com.example.Foo needs to access a component in the app but in a
> sub-package such as com.example.login.Login, this can be done in a
> similar way:
>
> <span t:type="login/Login"/>
>
> For methods that should return page names, they can return unqualified
> class names, qualified class names or even the class objects. The
> latter will allow easy refactoring.
>
> In summary, the idea is to use the concepts and facilities in Java
> as much as possible unless there is absolutely something critical
> that can't be done in Java. This will smooth the learning curve
> and probably reduce implementation effort.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
>
Re: T5: Component libraries
Posted by Kent Tong <ke...@cpttm.org.mo>.
Hi,
I think mapping from a prefix to a package (eg, core =>
org.apache.tapestry.corelib) may not be a good solution.
1) What if two organizations chooses the same prefix for their respective
library?
2) If I am working on a component in my app. If later I'd like to make
it available for others to use, I certainly shouldn't be forced to
add a prefix to all the type names. All I want is to pack it up.
Instead, I'd suggest that we use the fully qualified Java class
name as the component type name (eg, com.example.Bar). Of course
it's too long to type it. So, we can use a mechanism similar to
the Java import statement. That is, if component (or page)
com.example.Foo would like to use com.example.Bar in its template,
as they are in the same package, it can just the unqualified named:
<span t:type="Bar"/>
This requires that we no longer put pages into a "pages" sub-package
and components into "components" sub-package. Instead, put them into
the same package.
If com.example.Foo would like to use a component org.abc.Baz in a
library, it may specify the full name:
<span t:type="org/abc/Bar"/>
Or if Foo needs to use many such components from that library, it
can import the org.abc package somehow. Ideally, Tapestry should
use the import statements in Foo.java:
import org.abc.Bar;
class Foo {
}
To take care of the framework components, just assume the presence
of:
import org.apache.tapestry.corelib.components.*;
When there is ambiguity (eg, Bar appears in two imported packages),
then the same Java rule should apply and an explicit import is
required.
If com.example.Foo needs to access a component in the app but in a
sub-package such as com.example.login.Login, this can be done in a
similar way:
<span t:type="login/Login"/>
For methods that should return page names, they can return unqualified
class names, qualified class names or even the class objects. The
latter will allow easy refactoring.
In summary, the idea is to use the concepts and facilities in Java
as much as possible unless there is absolutely something critical
that can't be done in Java. This will smooth the learning curve
and probably reduce implementation effort.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: T5: Component libraries
Posted by Howard Lewis Ship <hl...@gmail.com>.
I think many, especially Geoff Longman, would agree that Tapestry 4
librarys/namespaces are a bit overengineered, and contain some unwanted
ambiguities.
Every T5 library will need to include a Tapestry IOC module.
The module will make a contribution to the
tapestry.ComponentClassResolverconfiguration. Example:
public static void
contributeComponentClassResolver(Configuration<LibraryMapping>
configuration)
{
configuration.add(new LibraryMapping("core", "
org.apache.tapestry.corelib"));
}
This maps pages, components and mixins under path "core/" to be inside the
.corelib package. "core" also has a privileged function, in that when a
name is not found elsewhere, core is searched. In this way, comopnents
inside core are available to the application without having to say
"core/TextField".
Say you created a nifty library:
@Contribute("tapestry.ComponentClassResolver")
public static void
contributeComponentClassResolver(Configuration<LibraryMapping>
configuration)
{
configuration.add(new LibraryMapping("nifty", "com.example.niftylib
"));
}
This does a few things, including setting up the packages below niftylib
(pages, components, mixins and base) to be loaded and reloaded by the
enhancing class loader.
You could then reference components in the library as t:id="nifty/Foo".
This is necessary both in the application, and inside other pages/components
inside the "nifty" library.
Unlike Tapestry 4, there aren't confusing and ambiguous nested hierarchys of
namespaces. Library authors will need to be sensible about providing a
reasonably unique path to keep from creating conflicts.
The folder name ("nifty") should not start or end with a slash, but may
contain one. This may help with ensuring non-conflicting names.
Tapestry may, soon, assume that the folder name is lower case. I'm looking
to ensure that at least the path portion of request URLs is case
insensitive.
On 1/9/07, Hugo Palma <hu...@gmail.com> wrote:
>
> How is support for component libraries being implemented in T5 ? I'm
> guessing the base component classes package is configured in the jar
> file manifest, is that it ?
>
> Cheers,
>
> Hugo
>
>
--
Howard M. Lewis Ship
TWD Consulting, Inc.
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Apache HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com