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 <pie...@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-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
