Re: Antwort: Re: Antwort: RE: T5 Decoupling a Template From its Component Class
On Tue, 2007-07-03 at 08:27 +0200, Kristian Marinkovic wrote:
>
> just remove the InjectService annotation from your service
> method and try it again :)
Cool, really easy :)
Thanx a lot,
cheers,
Martin
>
>
>
> Martin Grotzke
> <[EMAIL PROTECTED]>
>
> 02.07.2007 16:50
> Bitte antworten an
> "Tapestry users"
>
>
>
>
>
>An
> Tapestry users
>
> Kopie
>
> Thema
> Re: Antwort: RE:
> T5 Decoupling a
> Template >From
> its Component
> Class
>
>
>
>
>
>
>
>
> On Mon, 2007-07-02 at 16:06 +0200, Kristian Marinkovic wrote:
> >
> > service implementations contributed to the alias service will
> > override the other service implementations. this is also true for
> > implementations originally provided by tapestry
> >
> > the additional id is to distinguish multiple implementations of the
> > same interface. in your case you should only need it twice:
> > 1) to define your service
> > 2) to contribute to the alias service then you can forget it :)
>
> If I understand you correctly, you say that
>
> public static PageResponseRenderer decoratePageResponseRenderer(
> @InjectService("PageMarkupRenderer")
> final PageMarkupRenderer markupRenderer,
> @InjectService("MarkupWriterFactory")
> final MarkupWriterFactory markupWriterFactory,
> final Object delegate )
>
> should provide our custom MarkupWriterFactory?
> This is not the fact - with @InjectService("MarkupWriterFactory")
> T5 provides its MarkupWriterFactoryImpl and not our custom
> MarkupWriterFactory.
> Did I understand you wrong, or is this a "bug" in T5?
>
> Cheers,
> Martin
>
>
>
> >
> > g,
> > kris
> >
> >
> >
> > Martin Grotzke
> > <[EMAIL PROTECTED]>
> >
> > 02.07.2007 14:10
> > Bitte antworten an
> > "Tapestry users"
> >
> >
> >
> >
> >
> >An
> > Tapestry users
> >
> > Kopie
> >
> > Thema
> > RE: T5 Decoupling
> > a Template From
> > its Component
> > Class
> >
> >
> >
> >
> >
> >
> >
> >
> > On Mon, 2007-07-02 at 11:03 +0200, Kristian Marinkovic wrote:
> > >
> > > hi martin,
> > >
> > > if you use the ServiceBinder to contribute a class that implements
> > an
> > > already
> > > "contributed" interface you have to assign an id for your class by
> > > invoking withId,
> > > because the Interface is no longer sufficient to identifiy the
> > service
> > >
> > > binder.bind(PageTemplateLocator.class,
> > > MyPageTemplateLocatorImpl.class).withId("myLocator");
> > >
> > > furthermore you have to contribute to the aliasOverrides Service
> > > to actually replace the old implementation:
> > >
> > > public static void contributeAliasOverrides(
> > > @InjectService("myLocator") PageTemplateLocator
> > locator,
> > > Configuration configuration) {
> > >
> > >configuration.add(
> > > AliasContribution.create(
> > > PageTemplateLocator.class, locator));
> >
> > Great, this works - thanx a lot!
> >
> > Just for clarification: the specified id has to be used anywhere
> else,
> > right? E.g. for us the service in question is the
> MarkupWriterFactory,
> > and previously we also had this in our AppModule:
> >
> >public static PageResponseRenderer decoratePageResponseRenderer(
> >@InjectService("PageMarkupRenderer")
> > final PageMarkupRenderer markupRenderer,
> >@InjectService("MarkupWriterFactory")
> >final MarkupWriterFactory markupWriterFactory,
> >final Object delegate )
> >
> > which we have to change to @InjectService("myMarkupWriterFactory")
> > then.
> > Is this the intended way? Is it guaranteed, that T5 does not
> reference
> > the MarkupWriterFactory implementation by the id
> > "MarkupWriterFactory"?
> >
> > Thanx && cheers,
> > Martin
> >
> >
> > >
&g
Antwort: Re: Antwort: RE: T5 Decoupling a Template From its Component Class
just remove the InjectService annotation from your service
method and try it again :)
Martin Grotzke <[EMAIL PROTECTED]>
02.07.2007 16:50
Bitte antworten an
"Tapestry users"
An
Tapestry users
Kopie
Thema
Re: Antwort: RE: T5 Decoupling a Template From its Component Class
On Mon, 2007-07-02 at 16:06 +0200, Kristian Marinkovic wrote:
>
> service implementations contributed to the alias service will
> override the other service implementations. this is also true for
> implementations originally provided by tapestry
>
> the additional id is to distinguish multiple implementations of the
> same interface. in your case you should only need it twice:
> 1) to define your service
> 2) to contribute to the alias service then you can forget it :)
If I understand you correctly, you say that
public static PageResponseRenderer decoratePageResponseRenderer(
@InjectService("PageMarkupRenderer")
final PageMarkupRenderer markupRenderer,
@InjectService("MarkupWriterFactory")
final MarkupWriterFactory markupWriterFactory,
final Object delegate )
should provide our custom MarkupWriterFactory?
This is not the fact - with @InjectService("MarkupWriterFactory")
T5 provides its MarkupWriterFactoryImpl and not our custom
MarkupWriterFactory.
Did I understand you wrong, or is this a "bug" in T5?
Cheers,
Martin
>
> g,
> kris
>
>
>
> Martin Grotzke
> <[EMAIL PROTECTED]>
>
> 02.07.2007 14:10
> Bitte antworten an
> "Tapestry users"
>
>
>
>
>
>An
> Tapestry users
>
> Kopie
>
> Thema
> RE: T5 Decoupling
> a Template From
> its Component
> Class
>
>
>
>
>
>
>
>
> On Mon, 2007-07-02 at 11:03 +0200, Kristian Marinkovic wrote:
> >
> > hi martin,
> >
> > if you use the ServiceBinder to contribute a class that implements
> an
> > already
> > "contributed" interface you have to assign an id for your class by
> > invoking withId,
> > because the Interface is no longer sufficient to identifiy the
> service
> >
> > binder.bind(PageTemplateLocator.class,
> > MyPageTemplateLocatorImpl.class).withId("myLocator");
> >
> > furthermore you have to contribute to the aliasOverrides Service
> > to actually replace the old implementation:
> >
> > public static void contributeAliasOverrides(
> > @InjectService("myLocator") PageTemplateLocator
> locator,
> > Configuration configuration) {
> >
> >configuration.add(
> > AliasContribution.create(
> > PageTemplateLocator.class, locator));
>
> Great, this works - thanx a lot!
>
> Just for clarification: the specified id has to be used anywhere else,
> right? E.g. for us the service in question is the MarkupWriterFactory,
> and previously we also had this in our AppModule:
>
>public static PageResponseRenderer decoratePageResponseRenderer(
>@InjectService("PageMarkupRenderer")
>final PageMarkupRenderer markupRenderer,
>@InjectService("MarkupWriterFactory")
>final MarkupWriterFactory markupWriterFactory,
>final Object delegate )
>
> which we have to change to @InjectService("myMarkupWriterFactory")
> then.
> Is this the intended way? Is it guaranteed, that T5 does not reference
> the MarkupWriterFactory implementation by the id
> "MarkupWriterFactory"?
>
> Thanx && cheers,
> Martin
>
>
> >
> >
> > g,
> > kris
> >
> >
> >
> > Martin Grotzke
> > <[EMAIL PROTECTED]>
> >
> > 02.07.2007 10:00
> > Bitte antworten an
> > "Tapestry users"
> >
> >
> >
> >
> >
> >An
> > Tapestry users
> >
> > Kopie
> >
> > Thema
> > RE: T5 Decoupling
> > a Template From
> > its Component
> > Class
> >
> >
> >
> >
> >
> >
> >
> >
> > > Digging through the code I notice there is a PageTemplateLocator
> > > interface which seems like the appropriate service to override.
> What
> > I
> > > have tried is to add the following method to my AppModule
> class
> > >
> > >
> > > public static void bind(ServiceBinder binder) {
> > > S
Re: Antwort: RE: T5 Decoupling a Template From its Component Class
On Mon, 2007-07-02 at 16:06 +0200, Kristian Marinkovic wrote:
>
> service implementations contributed to the alias service will
> override the other service implementations. this is also true for
> implementations originally provided by tapestry
>
> the additional id is to distinguish multiple implementations of the
> same interface. in your case you should only need it twice:
> 1) to define your service
> 2) to contribute to the alias service then you can forget it :)
If I understand you correctly, you say that
public static PageResponseRenderer decoratePageResponseRenderer(
@InjectService("PageMarkupRenderer")
final PageMarkupRenderer markupRenderer,
@InjectService("MarkupWriterFactory")
final MarkupWriterFactory markupWriterFactory,
final Object delegate )
should provide our custom MarkupWriterFactory?
This is not the fact - with @InjectService("MarkupWriterFactory")
T5 provides its MarkupWriterFactoryImpl and not our custom
MarkupWriterFactory.
Did I understand you wrong, or is this a "bug" in T5?
Cheers,
Martin
>
> g,
> kris
>
>
>
> Martin Grotzke
> <[EMAIL PROTECTED]>
>
> 02.07.2007 14:10
> Bitte antworten an
> "Tapestry users"
>
>
>
>
>
> An
> Tapestry users
>
> Kopie
>
> Thema
> RE: T5 Decoupling
> a Template From
> its Component
> Class
>
>
>
>
>
>
>
>
> On Mon, 2007-07-02 at 11:03 +0200, Kristian Marinkovic wrote:
> >
> > hi martin,
> >
> > if you use the ServiceBinder to contribute a class that implements
> an
> > already
> > "contributed" interface you have to assign an id for your class by
> > invoking withId,
> > because the Interface is no longer sufficient to identifiy the
> service
> >
> > binder.bind(PageTemplateLocator.class,
> > MyPageTemplateLocatorImpl.class).withId("myLocator");
> >
> > furthermore you have to contribute to the aliasOverrides Service
> > to actually replace the old implementation:
> >
> > public static void contributeAliasOverrides(
> > @InjectService("myLocator") PageTemplateLocator
> locator,
> > Configuration configuration) {
> >
> >configuration.add(
> > AliasContribution.create(
> > PageTemplateLocator.class, locator));
>
> Great, this works - thanx a lot!
>
> Just for clarification: the specified id has to be used anywhere else,
> right? E.g. for us the service in question is the MarkupWriterFactory,
> and previously we also had this in our AppModule:
>
>public static PageResponseRenderer decoratePageResponseRenderer(
>@InjectService("PageMarkupRenderer")
>final PageMarkupRenderer markupRenderer,
>@InjectService("MarkupWriterFactory")
>final MarkupWriterFactory markupWriterFactory,
>final Object delegate )
>
> which we have to change to @InjectService("myMarkupWriterFactory")
> then.
> Is this the intended way? Is it guaranteed, that T5 does not reference
> the MarkupWriterFactory implementation by the id
> "MarkupWriterFactory"?
>
> Thanx && cheers,
> Martin
>
>
> >
> >
> > g,
> > kris
> >
> >
> >
> > Martin Grotzke
> > <[EMAIL PROTECTED]>
> >
> > 02.07.2007 10:00
> > Bitte antworten an
> > "Tapestry users"
> >
> >
> >
> >
> >
> >An
> > Tapestry users
> >
> > Kopie
> >
> > Thema
> > RE: T5 Decoupling
> > a Template From
> > its Component
> > Class
> >
> >
> >
> >
> >
> >
> >
> >
> > > Digging through the code I notice there is a PageTemplateLocator
> > > interface which seems like the appropriate service to override.
> What
> > I
> > > have tried is to add the following method to my AppModule
> class
> > >
> > >
> > > public static void bind(ServiceBinder binder) {
> > > ServiceBindingOptions options =
> > > binder.bind(
> > >
> > PageTemplateLocator.class,
> > >
> > MyPageTemplateLocatorImpl.class
> > >);
> > > }
>
Antwort: RE: T5 Decoupling a Template From its Component Class
service implementations contributed to the alias service will
override the other service implementations. this is also true for
implementations originally provided by tapestry
the additional id is to distinguish multiple implementations of the
same interface. in your case you should only need it twice:
1) to define your service
2) to contribute to the alias service then you can forget it :)
g,
kris
Martin Grotzke <[EMAIL PROTECTED]>
02.07.2007 14:10
Bitte antworten an
"Tapestry users"
An
Tapestry users
Kopie
Thema
RE: T5 Decoupling a Template From its Component Class
On Mon, 2007-07-02 at 11:03 +0200, Kristian Marinkovic wrote:
>
> hi martin,
>
> if you use the ServiceBinder to contribute a class that implements an
> already
> "contributed" interface you have to assign an id for your class by
> invoking withId,
> because the Interface is no longer sufficient to identifiy the service
>
> binder.bind(PageTemplateLocator.class,
> MyPageTemplateLocatorImpl.class).withId("myLocator");
>
> furthermore you have to contribute to the aliasOverrides Service
> to actually replace the old implementation:
>
> public static void contributeAliasOverrides(
> @InjectService("myLocator") PageTemplateLocator locator,
> Configuration configuration) {
>
>configuration.add(
> AliasContribution.create(
> PageTemplateLocator.class, locator));
Great, this works - thanx a lot!
Just for clarification: the specified id has to be used anywhere else,
right? E.g. for us the service in question is the MarkupWriterFactory,
and previously we also had this in our AppModule:
public static PageResponseRenderer decoratePageResponseRenderer(
@InjectService("PageMarkupRenderer")
final PageMarkupRenderer markupRenderer,
@InjectService("MarkupWriterFactory")
final MarkupWriterFactory markupWriterFactory,
final Object delegate )
which we have to change to @InjectService("myMarkupWriterFactory") then.
Is this the intended way? Is it guaranteed, that T5 does not reference
the MarkupWriterFactory implementation by the id "MarkupWriterFactory"?
Thanx && cheers,
Martin
>
>
> g,
> kris
>
>
>
> Martin Grotzke
> <[EMAIL PROTECTED]>
>
> 02.07.2007 10:00
> Bitte antworten an
> "Tapestry users"
>
>
>
>
>
>An
> Tapestry users
>
> Kopie
>
> Thema
> RE: T5 Decoupling
> a Template From
> its Component
> Class
>
>
>
>
>
>
>
>
> > Digging through the code I notice there is a PageTemplateLocator
> > interface which seems like the appropriate service to override. What
> I
> > have tried is to add the following method to my AppModule class
> >
> >
> > public static void bind(ServiceBinder binder) {
> > ServiceBindingOptions options =
> > binder.bind(
> >
> PageTemplateLocator.class,
> >
> MyPageTemplateLocatorImpl.class
> >);
> > }
> >
> >
> > ...but I get the following exception at startup.
> >
> >
> > java.lang.RuntimeException: Service id 'PageTemplateLocator' has
> already
> > been defined by
>
> Did you solve this issue? I get the same exception with another
> Service
> that's defined in TapestryModule that I want to override in my
> AppModule
> with my custom implementation...
>
> Thx && cheers,
> Martin
>
>
> On Wed, 2007-05-30 at 19:17 -0700, David Kendall wrote:
> > > From: Howard Lewis Ship [mailto:[EMAIL PROTECTED]
> > > Sent: Wednesday, May 30, 2007 5:15 PM
> > > There are internal services that can be overridden to handle
> those
> > > kinds of situations.
> > > The goal is to create something that works amazingly well for all
> > > the more typical cases, then start going after these others.
> Often
> > > it will involve moving a private interface out into the public
> space
> > ..
> >
> >
> >
> >
> > Thanks Howard - I appreciate your prompt response. However - I am
> not
> > clear if you are saying it cannot be done currently - or if you mean
> > that it can be done - but that I would be treading on somewhat
> unstable
> > ground given that the internal interfaces are subject to change.
> >
> > Digging through the code I notice there is a PageTemplateLocator
RE: T5 Decoupling a Template From its Component Class
On Mon, 2007-07-02 at 11:03 +0200, Kristian Marinkovic wrote:
>
> hi martin,
>
> if you use the ServiceBinder to contribute a class that implements an
> already
> "contributed" interface you have to assign an id for your class by
> invoking withId,
> because the Interface is no longer sufficient to identifiy the service
>
> binder.bind(PageTemplateLocator.class,
> MyPageTemplateLocatorImpl.class).withId("myLocator");
>
> furthermore you have to contribute to the aliasOverrides Service
> to actually replace the old implementation:
>
> public static void contributeAliasOverrides(
> @InjectService("myLocator") PageTemplateLocator locator,
> Configuration configuration) {
>
>configuration.add(
> AliasContribution.create(
> PageTemplateLocator.class, locator));
Great, this works - thanx a lot!
Just for clarification: the specified id has to be used anywhere else,
right? E.g. for us the service in question is the MarkupWriterFactory,
and previously we also had this in our AppModule:
public static PageResponseRenderer decoratePageResponseRenderer(
@InjectService("PageMarkupRenderer")
final PageMarkupRenderer markupRenderer,
@InjectService("MarkupWriterFactory")
final MarkupWriterFactory markupWriterFactory,
final Object delegate )
which we have to change to @InjectService("myMarkupWriterFactory") then.
Is this the intended way? Is it guaranteed, that T5 does not reference
the MarkupWriterFactory implementation by the id "MarkupWriterFactory"?
Thanx && cheers,
Martin
>
>
> g,
> kris
>
>
>
> Martin Grotzke
> <[EMAIL PROTECTED]>
>
> 02.07.2007 10:00
> Bitte antworten an
> "Tapestry users"
>
>
>
>
>
>An
> Tapestry users
>
> Kopie
>
> Thema
> RE: T5 Decoupling
> a Template From
> its Component
> Class
>
>
>
>
>
>
>
>
> > Digging through the code I notice there is a PageTemplateLocator
> > interface which seems like the appropriate service to override. What
> I
> > have tried is to add the following method to my AppModule class
> >
> >
> > public static void bind(ServiceBinder binder) {
> > ServiceBindingOptions options =
> > binder.bind(
> >
> PageTemplateLocator.class,
> >
> MyPageTemplateLocatorImpl.class
> >);
> > }
> >
> >
> > ...but I get the following exception at startup.
> >
> >
> > java.lang.RuntimeException: Service id 'PageTemplateLocator' has
> already
> > been defined by
>
> Did you solve this issue? I get the same exception with another
> Service
> that's defined in TapestryModule that I want to override in my
> AppModule
> with my custom implementation...
>
> Thx && cheers,
> Martin
>
>
> On Wed, 2007-05-30 at 19:17 -0700, David Kendall wrote:
> > > From: Howard Lewis Ship [mailto:[EMAIL PROTECTED]
> > > Sent: Wednesday, May 30, 2007 5:15 PM
> > > There are internal services that can be overridden to handle
> those
> > > kinds of situations.
> > > The goal is to create something that works amazingly well for all
> > > the more typical cases, then start going after these others.
> Often
> > > it will involve moving a private interface out into the public
> space
> > ..
> >
> >
> >
> >
> > Thanks Howard - I appreciate your prompt response. However - I am
> not
> > clear if you are saying it cannot be done currently - or if you mean
> > that it can be done - but that I would be treading on somewhat
> unstable
> > ground given that the internal interfaces are subject to change.
> >
> > Digging through the code I notice there is a PageTemplateLocator
> > interface which seems like the appropriate service to override. What
> I
> > have tried is to add the following method to my AppModule class
> >
> >
> > public static void bind(ServiceBinder binder) {
> > ServiceBindingOptions options =
> > binder.bind(
> >
> PageTemplateLocator.class,
> >
> MyPageTemplateLocatorImpl.class
> >);
> > }
> >
> >
> > ...but I get the following exception at startup.
> >
>
RE: T5 Decoupling a Template From its Component Class
hi martin,
if you use the ServiceBinder to contribute a class that implements an
already
"contributed" interface you have to assign an id for your class by
invoking withId,
because the Interface is no longer sufficient to identifiy the service
binder.bind(PageTemplateLocator.class,
MyPageTemplateLocatorImpl.class).withId("myLocator");
furthermore you have to contribute to the aliasOverrides Service
to actually replace the old implementation:
public static void contributeAliasOverrides(
@InjectService("myLocator") PageTemplateLocator locator,
Configuration configuration) {
configuration.add(
AliasContribution.create(
PageTemplateLocator.class, locator));
g,
kris
Martin Grotzke <[EMAIL PROTECTED]>
02.07.2007 10:00
Bitte antworten an
"Tapestry users"
An
Tapestry users
Kopie
Thema
RE: T5 Decoupling a Template From its Component Class
> Digging through the code I notice there is a PageTemplateLocator
> interface which seems like the appropriate service to override. What I
> have tried is to add the following method to my AppModule class
>
>
> public static void bind(ServiceBinder binder) {
> ServiceBindingOptions options =
>binder.bind(
> PageTemplateLocator.class,
> MyPageTemplateLocatorImpl.class
>);
> }
>
>
> ...but I get the following exception at startup.
>
>
> java.lang.RuntimeException: Service id 'PageTemplateLocator' has already
> been defined by
Did you solve this issue? I get the same exception with another Service
that's defined in TapestryModule that I want to override in my AppModule
with my custom implementation...
Thx && cheers,
Martin
On Wed, 2007-05-30 at 19:17 -0700, David Kendall wrote:
> > From: Howard Lewis Ship [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, May 30, 2007 5:15 PM
> > There are internal services that can be overridden to handle those
> > kinds of situations.
> > The goal is to create something that works amazingly well for all
> > the more typical cases, then start going after these others. Often
> > it will involve moving a private interface out into the public space
> ..
>
>
>
>
> Thanks Howard - I appreciate your prompt response. However - I am not
> clear if you are saying it cannot be done currently - or if you mean
> that it can be done - but that I would be treading on somewhat unstable
> ground given that the internal interfaces are subject to change.
>
> Digging through the code I notice there is a PageTemplateLocator
> interface which seems like the appropriate service to override. What I
> have tried is to add the following method to my AppModule class
>
>
> public static void bind(ServiceBinder binder) {
> ServiceBindingOptions options =
>binder.bind(
> PageTemplateLocator.class,
> MyPageTemplateLocatorImpl.class
>);
> }
>
>
> ...but I get the following exception at startup.
>
>
> java.lang.RuntimeException: Service id 'PageTemplateLocator' has already
> been defined by
> org.apache.tapestry.internal.services.InternalModule.build(AssetFactory,
> ComponentClassResolver) (at InternalModule.java:231) and may not be
> redefined by
> org.example.myapp.services.AppModule$MyPageTemplateLocatorImpl() (at
> AppModule.java:159). You should rename one of the service builder
> methods.
>
>
>
>
> Am I wasting my time trying this? I can tolerate a certain amount of
> instability when pulling in subsequent revisions of Tap5 - however - I
> would like to get a proof of concept up and running if at all possible.
>
> Any thoughts on this?
>
> Thanks again.
>
> David Kendall
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
--
Martin Grotzke
http://www.javakaffee.de/blog/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: T5 Decoupling a Template From its Component Class
> Digging through the code I notice there is a PageTemplateLocator
> interface which seems like the appropriate service to override. What I
> have tried is to add the following method to my AppModule class
>
>
> public static void bind(ServiceBinder binder) {
> ServiceBindingOptions options =
> binder.bind(
> PageTemplateLocator.class,
> MyPageTemplateLocatorImpl.class
> );
> }
>
>
> ...but I get the following exception at startup.
>
>
> java.lang.RuntimeException: Service id 'PageTemplateLocator' has already
> been defined by
Did you solve this issue? I get the same exception with another Service
that's defined in TapestryModule that I want to override in my AppModule
with my custom implementation...
Thx && cheers,
Martin
On Wed, 2007-05-30 at 19:17 -0700, David Kendall wrote:
> > From: Howard Lewis Ship [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, May 30, 2007 5:15 PM
> > There are internal services that can be overridden to handle those
> > kinds of situations.
> > The goal is to create something that works amazingly well for all
> > the more typical cases, then start going after these others. Often
> > it will involve moving a private interface out into the public space
> ..
>
>
>
>
> Thanks Howard - I appreciate your prompt response. However - I am not
> clear if you are saying it cannot be done currently - or if you mean
> that it can be done - but that I would be treading on somewhat unstable
> ground given that the internal interfaces are subject to change.
>
> Digging through the code I notice there is a PageTemplateLocator
> interface which seems like the appropriate service to override. What I
> have tried is to add the following method to my AppModule class
>
>
> public static void bind(ServiceBinder binder) {
> ServiceBindingOptions options =
> binder.bind(
> PageTemplateLocator.class,
> MyPageTemplateLocatorImpl.class
> );
> }
>
>
> ...but I get the following exception at startup.
>
>
> java.lang.RuntimeException: Service id 'PageTemplateLocator' has already
> been defined by
> org.apache.tapestry.internal.services.InternalModule.build(AssetFactory,
> ComponentClassResolver) (at InternalModule.java:231) and may not be
> redefined by
> org.example.myapp.services.AppModule$MyPageTemplateLocatorImpl() (at
> AppModule.java:159). You should rename one of the service builder
> methods.
>
>
>
>
> Am I wasting my time trying this? I can tolerate a certain amount of
> instability when pulling in subsequent revisions of Tap5 - however - I
> would like to get a proof of concept up and running if at all possible.
>
> Any thoughts on this?
>
> Thanks again.
>
> David Kendall
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
--
Martin Grotzke
http://www.javakaffee.de/blog/
signature.asc
Description: This is a digitally signed message part
Re: Lehky_SPAM: Re: T5 Decoupling a Template From its Component Class
yes, that;s still supported and documented here: http://tapestry.apache.org/tapestry5/tapestry-core/guide/localization.html On 5/31/07, Jiri Mares <[EMAIL PROTECTED]> wrote: Hi Howard, I would like to ask, whether there is still possibility to have localized templates? eg. org/example/myapp/components/CClamp.html org/example/myapp/components/CClamp_en.html org/example/myapp/components/CClamp_en_US.html org/example/myapp/components/CClamp_de.html Thanks Howard Lewis Ship napsal(a): > There are internal services that can be overridden to handle those kinds of > situations. > > The goal is to create something that works amazingly well for all the more > typical cases, then start going after these others. Often it will involve > moving a private interface out into the public space ... but once that's > done, its very hard to change the interface in the future without breaking > backwards compatibility, so we're pretty conservative about pulling back > the > curtain until we know the interface is full and complete. > > On 5/30/07, David Kendall <[EMAIL PROTECTED]> wrote: >> >> I am a Tapestry newbie getting up to speed on Tap 5. I am working on an >> application with extensive co-branding requirements. >> >> As I understand things, there is - by default - a tight coupling between >> a component class name and its template path. For example - if a >> component has a FQCN of... >> >> org.example.myapp.components.CClamp >> >> ...then the template has to be on the classpath as >> >> org/example/myapp/components/CClamp.html >> >> It would be very helpful if the mapping between the component and the >> template could be decoupled - this would allow me to pull in component >> templates that have been tweaked for a particular co-brand. >> >> For example - I might want to have a template on the class path as >> >> org/example/myapp/override/cobrand1/components/CClamp.html >> >> Is there any way to do this? >> >> Thanks in advance. >> >> David Kendall >> >> >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > -- Jiří Mareš (mailto:[EMAIL PROTECTED]) ČSAD SVT Praha, s.r.o. (http://www.svt.cz) Czech Republic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lehky_SPAM: Re: T5 Decoupling a Template From its Component Class
Hi Howard, I would like to ask, whether there is still possibility to have localized templates? eg. org/example/myapp/components/CClamp.html org/example/myapp/components/CClamp_en.html org/example/myapp/components/CClamp_en_US.html org/example/myapp/components/CClamp_de.html Thanks Howard Lewis Ship napsal(a): > There are internal services that can be overridden to handle those kinds of > situations. > > The goal is to create something that works amazingly well for all the more > typical cases, then start going after these others. Often it will involve > moving a private interface out into the public space ... but once that's > done, its very hard to change the interface in the future without breaking > backwards compatibility, so we're pretty conservative about pulling back > the > curtain until we know the interface is full and complete. > > On 5/30/07, David Kendall <[EMAIL PROTECTED]> wrote: >> >> I am a Tapestry newbie getting up to speed on Tap 5. I am working on an >> application with extensive co-branding requirements. >> >> As I understand things, there is - by default - a tight coupling between >> a component class name and its template path. For example - if a >> component has a FQCN of... >> >> org.example.myapp.components.CClamp >> >> ...then the template has to be on the classpath as >> >> org/example/myapp/components/CClamp.html >> >> It would be very helpful if the mapping between the component and the >> template could be decoupled - this would allow me to pull in component >> templates that have been tweaked for a particular co-brand. >> >> For example - I might want to have a template on the class path as >> >> org/example/myapp/override/cobrand1/components/CClamp.html >> >> Is there any way to do this? >> >> Thanks in advance. >> >> David Kendall >> >> >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > -- Jiří Mareš (mailto:[EMAIL PROTECTED]) ČSAD SVT Praha, s.r.o. (http://www.svt.cz) Czech Republic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: T5 Decoupling a Template From its Component Class
> From: Howard Lewis Ship [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, May 30, 2007 5:15 PM
> There are internal services that can be overridden to handle those
> kinds of situations.
> The goal is to create something that works amazingly well for all
> the more typical cases, then start going after these others. Often
> it will involve moving a private interface out into the public space
..
Thanks Howard - I appreciate your prompt response. However - I am not
clear if you are saying it cannot be done currently - or if you mean
that it can be done - but that I would be treading on somewhat unstable
ground given that the internal interfaces are subject to change.
Digging through the code I notice there is a PageTemplateLocator
interface which seems like the appropriate service to override. What I
have tried is to add the following method to my AppModule class
public static void bind(ServiceBinder binder) {
ServiceBindingOptions options =
binder.bind(
PageTemplateLocator.class,
MyPageTemplateLocatorImpl.class
);
}
...but I get the following exception at startup.
java.lang.RuntimeException: Service id 'PageTemplateLocator' has already
been defined by
org.apache.tapestry.internal.services.InternalModule.build(AssetFactory,
ComponentClassResolver) (at InternalModule.java:231) and may not be
redefined by
org.example.myapp.services.AppModule$MyPageTemplateLocatorImpl() (at
AppModule.java:159). You should rename one of the service builder
methods.
Am I wasting my time trying this? I can tolerate a certain amount of
instability when pulling in subsequent revisions of Tap5 - however - I
would like to get a proof of concept up and running if at all possible.
Any thoughts on this?
Thanks again.
David Kendall
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5 Decoupling a Template From its Component Class
There are internal services that can be overridden to handle those kinds of situations. The goal is to create something that works amazingly well for all the more typical cases, then start going after these others. Often it will involve moving a private interface out into the public space ... but once that's done, its very hard to change the interface in the future without breaking backwards compatibility, so we're pretty conservative about pulling back the curtain until we know the interface is full and complete. On 5/30/07, David Kendall <[EMAIL PROTECTED]> wrote: I am a Tapestry newbie getting up to speed on Tap 5. I am working on an application with extensive co-branding requirements. As I understand things, there is - by default - a tight coupling between a component class name and its template path. For example - if a component has a FQCN of... org.example.myapp.components.CClamp ...then the template has to be on the classpath as org/example/myapp/components/CClamp.html It would be very helpful if the mapping between the component and the template could be decoupled - this would allow me to pull in component templates that have been tweaked for a particular co-brand. For example - I might want to have a template on the class path as org/example/myapp/override/cobrand1/components/CClamp.html Is there any way to do this? Thanks in advance. David Kendall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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
