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/05/09 11:39:30 UTC
Re: T5: Component libraries
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 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