You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Pierce Wetter <pi...@paceap.com> on 2010/06/11 20:43:46 UTC
Complex Question about Templates and Inheritance
Ok, so I need to build 3 different apps that are very, very similar.
App #1 is for our customers, we'll call this app "cust"
App #2 is for our support staff, we'll call this app "support"
App #3 is for our engineering staff, we'll all this app "eng".
So my plan is to start by building a component/page library, which we'll call "platform".
Then my idea was to have each page and component in "platform" duplicated in each of the three applications as an empty super class. That is, in platform:
Page.java:
package com.paceap.platform;
public class Page
{
@Property
private String justSoThereIsSomethingToLookAtInTheClass;
}
Page.tml:
${justSoThereIsSomethingToLookAtInTheClass}
<t:aComponent>A component</t:aComponent>
AComponent.java:
public class AComponent
{
}
AComponent.tml:
<div>Just A Sample!</div>
Then in cust I would start with just the following:
Page.java:
package com.paceap.cust;
public class Page extends com.paceap.platform.Page
{
// nothing to begin with.
}
AComponent.java:
public class AComponent extends com.paceap.platform.AComponent
{
// nothing to begin with
}
My idea here is that I want to take advantage of the inheritance facilities so that I only have to specify the differences between the 3 applications. I already know that if there is no .tml file Tapestry will look for the superclasses .tml file. That is, if in my Customer app I ask for <t:pagelink page="Page">, it will use com.paceap.cust.Page.java for the class for Page, but seeing that com.paceap.cust.Page.tml is not to be found, it will use com.paceap.platform.Page.tml instead. So I should be able to override all behavior in any of the 3 applications at the page level by overriding things in the local version of the .java file, or adding a new .tml file to the local version.
But here are my two questions at last:
1. Is is really necessary for me to have the stub classes in each app? Or will Tapestry map page="Page" to "platform/Page" if "Page.java" isn't found locally. Then I only need add a new Page.java as needed.
2. So in the platform library, Page references "aComponent". If I provide a new "AComponent" in the application layer will that override the mapping in the platform layer so that aComponent down in platform/Page.tml is now understood to refer to cust/AComponent, not platform/AComponent? Or would I have to cut/paste platform/Page.tml into cust/Page.tml so that it would resolve using the local resources instead.
Put another way, ignoring all my stuff, I made my own platform/GridPager component, which one would tapestry use when displaying a Grid. Mine or the one in corelib?
Pierce
Re: Complex Question about Templates and Inheritance
Posted by Pierce Wetter <pi...@paceap.com>.
> If you map your PlatformModule to "core" then your components and
> pages can be accessed without a prefix. Your page classes would live
> in x.y.platform.pages.
>
> In PlatformModule.java
> public static void
> contributeComponentClassResolver(Configuration<LibraryMapping>
> configuration) {
> configuration.add(new LibraryMapping("core", "x.y.platform"));
> }
>
> Your cust/support/eng projects would just include the PlatformModule
> and by default would all be the same.
>
>
> The key is mapping your module to "core" which is special. This won't
> work the same for other modules.
Ah, I never would have gotten that bit, thanks.
Another gotcha:
@InjectPage
private Index index;
Has to change to:
@InjectPage("Index")
private Object index;
Pierce
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Complex Question about Templates and Inheritance
Posted by "Nourredine K." <no...@yahoo.com>.
Josh Canfield wrote:
>
>
> Thiago is right. Currently the way this works is an implementation
> detail and not a documented feature so you end up setting yourself up
> for much pain if it stops working that way in the future... Maybe we
> can document the order libraries are loaded, or something to make this
> a supported feature....
>
>
I wasn't aware of the "@Submodule" and "auto-loading" logic in term of
module loading order.
I remember I had the same issue [1] and I had to implement a decorator for
the ComponentClassResolver service to modify the module loading order (using
java reflection: ugly but no better solution found at that moment [2]).
I still think that it could be very interresting to handle ordered lists for
ComponentClassResolver contributions to provide GUI extensibility.
[1] http://www.mail-archive.com/users@tapestry.apache.org/msg43088.html
[2] http://www.mail-archive.com/users@tapestry.apache.org/msg34196.html
Nourredine.
--
View this message in context: http://old.nabble.com/Complex-Question-about-Templates-and-Inheritance-tp28858822p28870316.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Complex Question about Templates and Inheritance
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Mon, 14 Jun 2010 14:44:35 -0300, Pierce Wetter <pi...@paceap.com>
wrote:
> Since core is already "special" it seems like it makes sense to have
> the ability to do specific overrides. Sure its not as general as being
> able to say "everything in this package is also in core", but I think
> overly general is dangerous for core anyways.
You can always file a JIRA for it or, better yet, add a patch that
implements it. :)
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Complex Question about Templates and Inheritance
Posted by Pierce Wetter <pi...@paceap.com>.
For the record, I found out today that I had to remove the ComponentClassResolver contribution from the library module, and then do both of them in the AppModule:
public static void contributeComponentClassResolver(Configuration<LibraryMapping> configuration)
{
configuration.add(new LibraryMapping("pace", "com.paceap.platform"));
configuration.add(new LibraryMapping("pace", "com.paceap.cust"));
}
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Complex Question about Templates and Inheritance
Posted by Josh Canfield <jo...@gmail.com>.
I wouldn't minding being able to override any module mapping. Your
(Pierce's) example is very reasonable. A more general example might be
a CMS module that you want to deploy for several clients. It includes
a complete working site but needs to be tweaked a bit for clients.
Perhaps there is a Login component that you want to extend without
having to recreate all the pages that include the component.
As an aside: For your extended pages you can add a link transformer so
that links pointing to the old page are redirected to the extended
page...
Josh
On Mon, Jun 14, 2010 at 10:44 AM, Pierce Wetter <pi...@paceap.com> wrote:
>
> On Jun 12, 2010, at 9:54 PM, Josh Canfield wrote:
>
>>> But I think there should be a mechanism for overriding core components, even if you had to do each one explicitly.
>>
>> Thiago is right. Currently the way this works is an implementation
>> detail and not a documented feature so you end up setting yourself up
>> for much pain if it stops working that way in the future... Maybe we
>> can document the order libraries are loaded, or something to make this
>> a supported feature....
>
> I was thinking more along the lines of some method where you would contribute an explicit override:
>
>
> overrideCoreComponent("GridPager", "com.mydomain.components.GridPager");
>
> Since core is already "special" it seems like it makes sense to have the ability to do specific overrides. Sure its not as general as being able to say "everything in this package is also in core", but I think overly general is dangerous for core anyways.
>
> Just my $.02.
>
> Pierce
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
--
http://www.bodylabgym.com - a private, by appointment only, one-on-one
health and fitness facility.
--
http://www.ectransition.com - Quality Electronic Cigarettes at a
reasonable price!
--
TheDailyTube.com. Sign up and get the best new videos on the internet
delivered fresh to your inbox.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Complex Question about Templates and Inheritance
Posted by Pierce Wetter <pi...@paceap.com>.
On Jun 12, 2010, at 9:54 PM, Josh Canfield wrote:
>> But I think there should be a mechanism for overriding core components, even if you had to do each one explicitly.
>
> Thiago is right. Currently the way this works is an implementation
> detail and not a documented feature so you end up setting yourself up
> for much pain if it stops working that way in the future... Maybe we
> can document the order libraries are loaded, or something to make this
> a supported feature....
I was thinking more along the lines of some method where you would contribute an explicit override:
overrideCoreComponent("GridPager", "com.mydomain.components.GridPager");
Since core is already "special" it seems like it makes sense to have the ability to do specific overrides. Sure its not as general as being able to say "everything in this package is also in core", but I think overly general is dangerous for core anyways.
Just my $.02.
Pierce
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Complex Question about Templates and Inheritance
Posted by Josh Canfield <jo...@gmail.com>.
> But I think there should be a mechanism for overriding core components, even if you had to do each one explicitly.
Thiago is right. Currently the way this works is an implementation
detail and not a documented feature so you end up setting yourself up
for much pain if it stops working that way in the future... Maybe we
can document the order libraries are loaded, or something to make this
a supported feature....
On Sat, Jun 12, 2010 at 1:57 PM, Pierce Wetter <pi...@paceap.com> wrote:
>
> On Jun 12, 2010, at 1:08 PM, Thiago H. de Paula Figueiredo wrote:
>
>> On Sat, 12 Jun 2010 16:41:56 -0300, Pierce Wetter <pi...@paceap.com> wrote:
>>
>>> Well, despite your reservations it seems to be working. Perhaps the other modules are loaded before the app module so that contributeComponentClassResolver gets called after the one for AppModule. Looking at the log...
>>
>> That's why adding a 'core' module is a bad thing: it relies in the module loading ordering when no promise of this kind is made.
>
> Well, SubModules are always loaded second it seems. But I suppose you can't rely on the auto loading order.
>
> But I think there should be a mechanism for overriding core components, even if you had to do each one explicitly. For instance, it would be a great and wonderful thing if someone made a drop in replacement for Grid that used the ExtJS stuff.
>
>>
>>> <t:pace.foo />
>>> Must be turned into:
>>> <span t:type="pace/foo" />
>>> because t:type="pace.foo" won't work. Did I do something wrong, or is that a known issue?
>>
>> This is working as expected and documented.
>
> Ok, good to know.
>
> pierce
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
--
http://www.bodylabgym.com - a private, by appointment only, one-on-one
health and fitness facility.
--
http://www.ectransition.com - Quality Electronic Cigarettes at a
reasonable price!
--
TheDailyTube.com. Sign up and get the best new videos on the internet
delivered fresh to your inbox.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Complex Question about Templates and Inheritance
Posted by Pierce Wetter <pi...@paceap.com>.
On Jun 12, 2010, at 1:08 PM, Thiago H. de Paula Figueiredo wrote:
> On Sat, 12 Jun 2010 16:41:56 -0300, Pierce Wetter <pi...@paceap.com> wrote:
>
>> Well, despite your reservations it seems to be working. Perhaps the other modules are loaded before the app module so that contributeComponentClassResolver gets called after the one for AppModule. Looking at the log...
>
> That's why adding a 'core' module is a bad thing: it relies in the module loading ordering when no promise of this kind is made.
Well, SubModules are always loaded second it seems. But I suppose you can't rely on the auto loading order.
But I think there should be a mechanism for overriding core components, even if you had to do each one explicitly. For instance, it would be a great and wonderful thing if someone made a drop in replacement for Grid that used the ExtJS stuff.
>
>> <t:pace.foo />
>> Must be turned into:
>> <span t:type="pace/foo" />
>> because t:type="pace.foo" won't work. Did I do something wrong, or is that a known issue?
>
> This is working as expected and documented.
Ok, good to know.
pierce
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Complex Question about Templates and Inheritance
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Sat, 12 Jun 2010 16:41:56 -0300, Pierce Wetter <pi...@paceap.com>
wrote:
> Well, despite your reservations it seems to be working. Perhaps the
> other modules are loaded before the app module so that
> contributeComponentClassResolver gets called after the one for
> AppModule. Looking at the log...
That's why adding a 'core' module is a bad thing: it relies in the module
loading ordering when no promise of this kind is made.
> <t:pace.foo />
> Must be turned into:
> <span t:type="pace/foo" />
> because t:type="pace.foo" won't work. Did I do something wrong, or is
> that a known issue?
This is working as expected and documented.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Complex Question about Templates and Inheritance
Posted by Pierce Wetter <pi...@paceap.com>.
On Jun 11, 2010, at 8:53 PM, Josh Canfield wrote:
>> So in PlatformModule, I would need to do:
>>
>> public static void
>> contributeComponentClassResolver(Configuration<LibraryMapping>
>> configuration) {
>> configuration.add(new LibraryMapping("paceap", "com.paceap.platform"));
>> }
>>
>> Then in AppModule, I would need to do:
>>
>> public static void
>> contributeComponentClassResolver(Configuration<LibraryMapping>
>> configuration) {
>> configuration.add(new LibraryMapping("paceap", "com.paceap.cust"));
>> }
>
> Have you tried this? It doesn't look like it would work.
Well, despite your reservations it seems to be working. Perhaps the other modules are loaded before the app module so that contributeComponentClassResolver gets called after the one for AppModule. Looking at the log...
Adding module definition for class org.apache.tapestry5.ioc.services.TapestryIOCModule
Adding module definition for class com.paceap.eden.sean.services.SeanModule <-- my platform module
Adding module definition for class org.tynamo.jpa.JPACoreModule <-- sub modules of platform module
Adding module definition for class org.tynamo.jpa.JPAModule <-- sub modules of platform module
Adding module definition for class com.paceap.eden.sean.services.ShiroSecurityModule <-- sub modules of platform module
Adding module definition for class org.tynamo.security.services.SecurityModule <-- sub modules of platform module
Adding module definition for class org.apache.tapestry5.services.TapestryModule
Adding module definition for class org.apache.tapestry5.internal.services.InternalModule
Adding module definition for class com.paceap.eden.schematool.services.AppModule
So AppModule is loaded last. It seems that "auto-loaded" modules are loaded first, while SubModules are loaded second. So if you're using @SubModule, that's the problem, you need to make the manifest change to auto-load your module.
Meanwhile the overrides seem to be working:
Originally, I started with a working app.
I copied that app to a new folder, changed that folder to "Sean" (named after Sean Connery, its a bad internal joke because the support app is named Zardoz).
I changed Sean/pom.xml to build a library. I removed the app specific pages from the library (like Index), and from the old app I removed all the component.java and .tml definitions, leaving mostly empty folders. The exception was Layout.java and Layout.tml. I modified the app to subclass the implementation in Sean, and modified the app's Layout.tml to have some extra HTML.
So I have only about 10 pages (out of 322) defined in the app, and in the library, I have everything else (759 pages and components) defined in the library.
One gotcha I'm having is that if I use invisible instrumentation, the type specifier has to have a / instead of a .:
<t:pace.foo />
Must be turned into:
<span t:type="pace/foo" />
because t:type="pace.foo" won't work. Did I do something wrong, or is that a known issue?
Pierce
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Complex Question about Templates and Inheritance
Posted by Pierce Wetter <pi...@paceap.com>.
On Jun 12, 2010, at 11:09 AM, Jim O'Callaghan wrote:
> Pierce,
>
> The RegexAuthorizer has been removed from more recent snapshots of T5.2.0 -
> search the list - I've posted a few questions about it in the last few
> weeks.
Doh! The formos docs about making a component library are out of date then.
Thanks for the heads up, .
OK, so I was assuming that the fact that I was getting an error about not being able to find: 'context:css/default.css' since moving 95% of my code into a component library was a permissions thing.
Now I'm guessing perhaps I need to contribute a ClasspathAssetAliasManager. Sigh. More docs to figure out.
Pierce
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
RE: Complex Question about Templates and Inheritance
Posted by Jim O'Callaghan <jc...@yahoo.co.uk>.
Pierce,
The RegexAuthorizer has been removed from more recent snapshots of T5.2.0 -
search the list - I've posted a few questions about it in the last few
weeks.
Regards,
Jim.
-----Original Message-----
From: Pierce Wetter [mailto:pierce@paceap.com]
Sent: 12 June 2010 18:35
To: Tapestry users
Subject: Re: Complex Question about Templates and Inheritance
On Jun 11, 2010, at 8:53 PM, Josh Canfield wrote:
>> So in PlatformModule, I would need to do:
>>
>> public static void
>> contributeComponentClassResolver(Configuration<LibraryMapping>
>> configuration) {
>> configuration.add(new LibraryMapping("paceap",
"com.paceap.platform"));
>> }
>>
>> Then in AppModule, I would need to do:
>>
>> public static void
>> contributeComponentClassResolver(Configuration<LibraryMapping>
>> configuration) {
>> configuration.add(new LibraryMapping("paceap", "com.paceap.cust"));
>> }
>
> Have you tried this? It doesn't look like it would work. The way that
> library mappings are handled in the ComponentClassResolver each
> library is scanned for component/page/mixin classes and mapped to a
> name. The first thing it does is is scan the app package, then it
> scans all the library packages. Items are stored in a map and so the
> last one in wins and so your app should never win.
>
> The reason using "core" works (at least in 5.1.0.5) is because when
> looking for a component Tapestry first checks your app packages, then
> checks the core module.
Well, I've coded it. It's not working yet because I'm having some other
issue with maven loading a stale version of 5.2, so it can't find
RegexAuthorizer.
But the last-one-in-wins thing seems fixable, I just take the
contributeComponentClassResolver out of the PlatformModule entirely, and put
the call into AppModule only in the right order.
Pierce
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Complex Question about Templates and Inheritance
Posted by Pierce Wetter <pi...@paceap.com>.
On Jun 11, 2010, at 8:53 PM, Josh Canfield wrote:
>> So in PlatformModule, I would need to do:
>>
>> public static void
>> contributeComponentClassResolver(Configuration<LibraryMapping>
>> configuration) {
>> configuration.add(new LibraryMapping("paceap", "com.paceap.platform"));
>> }
>>
>> Then in AppModule, I would need to do:
>>
>> public static void
>> contributeComponentClassResolver(Configuration<LibraryMapping>
>> configuration) {
>> configuration.add(new LibraryMapping("paceap", "com.paceap.cust"));
>> }
>
> Have you tried this? It doesn't look like it would work. The way that
> library mappings are handled in the ComponentClassResolver each
> library is scanned for component/page/mixin classes and mapped to a
> name. The first thing it does is is scan the app package, then it
> scans all the library packages. Items are stored in a map and so the
> last one in wins and so your app should never win.
>
> The reason using "core" works (at least in 5.1.0.5) is because when
> looking for a component Tapestry first checks your app packages, then
> checks the core module.
Well, I've coded it. It's not working yet because I'm having some other issue with maven loading a stale version of 5.2, so it can't find RegexAuthorizer.
But the last-one-in-wins thing seems fixable, I just take the contributeComponentClassResolver out of the PlatformModule entirely, and put the call into AppModule only in the right order.
Pierce
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Complex Question about Templates and Inheritance
Posted by Josh Canfield <jo...@gmail.com>.
> So in PlatformModule, I would need to do:
>
> public static void
> contributeComponentClassResolver(Configuration<LibraryMapping>
> configuration) {
> configuration.add(new LibraryMapping("paceap", "com.paceap.platform"));
> }
>
> Then in AppModule, I would need to do:
>
> public static void
> contributeComponentClassResolver(Configuration<LibraryMapping>
> configuration) {
> configuration.add(new LibraryMapping("paceap", "com.paceap.cust"));
> }
Have you tried this? It doesn't look like it would work. The way that
library mappings are handled in the ComponentClassResolver each
library is scanned for component/page/mixin classes and mapped to a
name. The first thing it does is is scan the app package, then it
scans all the library packages. Items are stored in a map and so the
last one in wins and so your app should never win.
The reason using "core" works (at least in 5.1.0.5) is because when
looking for a component Tapestry first checks your app packages, then
checks the core module.
Josh
On Fri, Jun 11, 2010 at 3:58 PM, Pierce Wetter <pi...@paceap.com> wrote:
>
> On Jun 11, 2010, at 3:31 PM, Manuel Sugawara wrote:
>
>> On Fri, Jun 11, 2010 at 4:35 PM, Josh Canfield <jo...@gmail.com>wrote:
>>
>>> Read the bit about template inheritance at the bottom of this page:
>>> http://tapestry.apache.org/tapestry5.1/guide/templates.html
>>> Although I agree with the sentiment in that page about not overusing
>>> these features and preferring composition over inheritance.
>>>
>>> If you map your PlatformModule to "core" then your components and
>>> pages can be accessed without a prefix. Your page classes would live
>>> in x.y.platform.pages.
>>>
>>
>> Just be careful that this might not work in the upcoming tapestry release.
>> See this link<http://old.nabble.com/Re:-Libarary-"core"-mapping-not-working-in-5.2.0-SNAPSHOT-p28758883.html>
>> .
>>
>> Regards,<http://old.nabble.com/Re:-Libarary-"core"-mapping-not-working-in-5.2.0-SNAPSHOT-p28758883.html>
>> Manuel.
>
>
> ARRGH! I'm using 5.2.0-SNAPSHOT.
>
> Hmmm... And Howard kind of blew you off.
>
> I think Howard is wrong in this case, I think I can see reasons why you might want to supplant core things, like change the GridPager or something.
>
> But looking at the error (which seems to have nothing to do with supplanting core but rather a detail of LibraryMappings), what this seems to be saying is that it wants a common base package of at least two elements.
>
> So in PlatformModule, I would need to do:
>
> public static void
> contributeComponentClassResolver(Configuration<LibraryMapping>
> configuration) {
> configuration.add(new LibraryMapping("paceap", "com.paceap.platform"));
> }
>
> Then in AppModule, I would need to do:
>
> public static void
> contributeComponentClassResolver(Configuration<LibraryMapping>
> configuration) {
> configuration.add(new LibraryMapping("paceap", "com.paceap.cust"));
> }
>
> Then tapestry will be happy because it can reduce that to "com.paceap", which is two terms. I'll have to change every component reference to have "paceap" in front, i.e.: <t:paceap.foo />
>
> Though if its going to reduce these to a base package, one wonders if it would resolve paceap.foo to a class in com.paceap.not.included.in.the.library.mapping as well, which definitely seems like a bug!
>
> Pierce
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
--
http://www.bodylabgym.com - a private, by appointment only, one-on-one
health and fitness facility.
--
http://www.ectransition.com - Quality Electronic Cigarettes at a
reasonable price!
--
TheDailyTube.com. Sign up and get the best new videos on the internet
delivered fresh to your inbox.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Complex Question about Templates and Inheritance
Posted by Pierce Wetter <pi...@paceap.com>.
On Jun 11, 2010, at 3:31 PM, Manuel Sugawara wrote:
> On Fri, Jun 11, 2010 at 4:35 PM, Josh Canfield <jo...@gmail.com>wrote:
>
>> Read the bit about template inheritance at the bottom of this page:
>> http://tapestry.apache.org/tapestry5.1/guide/templates.html
>> Although I agree with the sentiment in that page about not overusing
>> these features and preferring composition over inheritance.
>>
>> If you map your PlatformModule to "core" then your components and
>> pages can be accessed without a prefix. Your page classes would live
>> in x.y.platform.pages.
>>
>
> Just be careful that this might not work in the upcoming tapestry release.
> See this link<http://old.nabble.com/Re:-Libarary-"core"-mapping-not-working-in-5.2.0-SNAPSHOT-p28758883.html>
> .
>
> Regards,<http://old.nabble.com/Re:-Libarary-"core"-mapping-not-working-in-5.2.0-SNAPSHOT-p28758883.html>
> Manuel.
ARRGH! I'm using 5.2.0-SNAPSHOT.
Hmmm... And Howard kind of blew you off.
I think Howard is wrong in this case, I think I can see reasons why you might want to supplant core things, like change the GridPager or something.
But looking at the error (which seems to have nothing to do with supplanting core but rather a detail of LibraryMappings), what this seems to be saying is that it wants a common base package of at least two elements.
So in PlatformModule, I would need to do:
public static void
contributeComponentClassResolver(Configuration<LibraryMapping>
configuration) {
configuration.add(new LibraryMapping("paceap", "com.paceap.platform"));
}
Then in AppModule, I would need to do:
public static void
contributeComponentClassResolver(Configuration<LibraryMapping>
configuration) {
configuration.add(new LibraryMapping("paceap", "com.paceap.cust"));
}
Then tapestry will be happy because it can reduce that to "com.paceap", which is two terms. I'll have to change every component reference to have "paceap" in front, i.e.: <t:paceap.foo />
Though if its going to reduce these to a base package, one wonders if it would resolve paceap.foo to a class in com.paceap.not.included.in.the.library.mapping as well, which definitely seems like a bug!
Pierce
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Complex Question about Templates and Inheritance
Posted by Josh Canfield <jo...@gmail.com>.
Yeah.. I remember that email now. I stick my common component library
into "core" as well. It looks like this is used for auto-generating
library mappings to classpath asset urls for the
ClasspathAssetAliasManager... Maybe somebody can think of a different
way to do this? Or perhaps how to configure exceptions for overrides?
Josh
On Fri, Jun 11, 2010 at 3:31 PM, Manuel Sugawara
<ma...@gmail.com> wrote:
> On Fri, Jun 11, 2010 at 4:35 PM, Josh Canfield <jo...@gmail.com>wrote:
>
>> Read the bit about template inheritance at the bottom of this page:
>> http://tapestry.apache.org/tapestry5.1/guide/templates.html
>> Although I agree with the sentiment in that page about not overusing
>> these features and preferring composition over inheritance.
>>
>> If you map your PlatformModule to "core" then your components and
>> pages can be accessed without a prefix. Your page classes would live
>> in x.y.platform.pages.
>>
>
> Just be careful that this might not work in the upcoming tapestry release.
> See this link<http://old.nabble.com/Re:-Libarary-"core"-mapping-not-working-in-5.2.0-SNAPSHOT-p28758883.html>
> .
>
> Regards,<http://old.nabble.com/Re:-Libarary-"core"-mapping-not-working-in-5.2.0-SNAPSHOT-p28758883.html>
> Manuel.
>
--
--
http://www.bodylabgym.com - a private, by appointment only, one-on-one
health and fitness facility.
--
http://www.ectransition.com - Quality Electronic Cigarettes at a
reasonable price!
--
TheDailyTube.com. Sign up and get the best new videos on the internet
delivered fresh to your inbox.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Complex Question about Templates and Inheritance
Posted by Manuel Sugawara <ma...@gmail.com>.
On Fri, Jun 11, 2010 at 4:35 PM, Josh Canfield <jo...@gmail.com>wrote:
> Read the bit about template inheritance at the bottom of this page:
> http://tapestry.apache.org/tapestry5.1/guide/templates.html
> Although I agree with the sentiment in that page about not overusing
> these features and preferring composition over inheritance.
>
> If you map your PlatformModule to "core" then your components and
> pages can be accessed without a prefix. Your page classes would live
> in x.y.platform.pages.
>
Just be careful that this might not work in the upcoming tapestry release.
See this link<http://old.nabble.com/Re:-Libarary-"core"-mapping-not-working-in-5.2.0-SNAPSHOT-p28758883.html>
.
Regards,<http://old.nabble.com/Re:-Libarary-"core"-mapping-not-working-in-5.2.0-SNAPSHOT-p28758883.html>
Manuel.
Re: Complex Question about Templates and Inheritance
Posted by Josh Canfield <jo...@gmail.com>.
Read the bit about template inheritance at the bottom of this page:
http://tapestry.apache.org/tapestry5.1/guide/templates.html
Although I agree with the sentiment in that page about not overusing
these features and preferring composition over inheritance.
If you map your PlatformModule to "core" then your components and
pages can be accessed without a prefix. Your page classes would live
in x.y.platform.pages.
In PlatformModule.java
public static void
contributeComponentClassResolver(Configuration<LibraryMapping>
configuration) {
configuration.add(new LibraryMapping("core", "x.y.platform"));
}
Your cust/support/eng projects would just include the PlatformModule
and by default would all be the same.
Since Tapestry looks in your application components/pages before
looking in core you can replace pages/components from core with your
own implementation.
So for instance, if you provide a page named PageA in you
PlatformModule it would be in the x.y.platform.pages package and have
a template that also lived in that package. If you want to replace
PageA in your specific install then you implement
x.y.yourpackage.pages.PageA and it gets loaded instead of the page
from the PlatformModule. Your new page can inherit from the
PlatformModule's page and use the <t:extension-point> tags, or
wholesale replace the template.
The key is mapping your module to "core" which is special. This won't
work the same for other modules.
Good Luck!
Josh
On Fri, Jun 11, 2010 at 11:43 AM, Pierce Wetter <pi...@paceap.com> wrote:
>
> Ok, so I need to build 3 different apps that are very, very similar.
>
> App #1 is for our customers, we'll call this app "cust"
> App #2 is for our support staff, we'll call this app "support"
> App #3 is for our engineering staff, we'll all this app "eng".
>
> So my plan is to start by building a component/page library, which we'll call "platform".
>
> Then my idea was to have each page and component in "platform" duplicated in each of the three applications as an empty super class. That is, in platform:
>
> Page.java:
>
> package com.paceap.platform;
>
> public class Page
> {
> @Property
> private String justSoThereIsSomethingToLookAtInTheClass;
> }
>
>
> Page.tml:
>
> ${justSoThereIsSomethingToLookAtInTheClass}
>
> <t:aComponent>A component</t:aComponent>
>
> AComponent.java:
>
> public class AComponent
> {
> }
>
> AComponent.tml:
>
> <div>Just A Sample!</div>
>
> Then in cust I would start with just the following:
>
> Page.java:
>
> package com.paceap.cust;
>
> public class Page extends com.paceap.platform.Page
> {
> // nothing to begin with.
> }
>
> AComponent.java:
>
> public class AComponent extends com.paceap.platform.AComponent
> {
> // nothing to begin with
> }
>
>
> My idea here is that I want to take advantage of the inheritance facilities so that I only have to specify the differences between the 3 applications. I already know that if there is no .tml file Tapestry will look for the superclasses .tml file. That is, if in my Customer app I ask for <t:pagelink page="Page">, it will use com.paceap.cust.Page.java for the class for Page, but seeing that com.paceap.cust.Page.tml is not to be found, it will use com.paceap.platform.Page.tml instead. So I should be able to override all behavior in any of the 3 applications at the page level by overriding things in the local version of the .java file, or adding a new .tml file to the local version.
>
> But here are my two questions at last:
>
> 1. Is is really necessary for me to have the stub classes in each app? Or will Tapestry map page="Page" to "platform/Page" if "Page.java" isn't found locally. Then I only need add a new Page.java as needed.
>
> 2. So in the platform library, Page references "aComponent". If I provide a new "AComponent" in the application layer will that override the mapping in the platform layer so that aComponent down in platform/Page.tml is now understood to refer to cust/AComponent, not platform/AComponent? Or would I have to cut/paste platform/Page.tml into cust/Page.tml so that it would resolve using the local resources instead.
>
> Put another way, ignoring all my stuff, I made my own platform/GridPager component, which one would tapestry use when displaying a Grid. Mine or the one in corelib?
>
> Pierce
>
>
>
>
>
>
--
--
http://www.bodylabgym.com - a private, by appointment only, one-on-one
health and fitness facility.
--
http://www.ectransition.com - Quality Electronic Cigarettes at a
reasonable price!
--
TheDailyTube.com. Sign up and get the best new videos on the internet
delivered fresh to your inbox.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org