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 users@tapestry.apache.org
An
Tapestry users users@tapestry.apache.org
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
users@tapestry.apache.org
An
Tapestry users
users@tapestry.apache.org
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,
ConfigurationAliasContribution 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
users@tapestry.apache.org
An
Tapestry users
users@tapestry.apache.org
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
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
users@tapestry.apache.org
An
Tapestry users
users@tapestry.apache.org
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
users@tapestry.apache.org
An
Tapestry users
users@tapestry.apache.org
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,
ConfigurationAliasContribution 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
users@tapestry.apache.org
An
Tapestry users
users@tapestry.apache.org
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
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: 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,
ConfigurationAliasContribution configuration) {
configuration.add(
AliasContribution.create(
PageTemplateLocator.class, locator));
g,
kris
Martin Grotzke [EMAIL PROTECTED]
02.07.2007 10:00
Bitte antworten an
Tapestry users users@tapestry.apache.org
An
Tapestry users users@tapestry.apache.org
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
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,
ConfigurationAliasContribution 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
users@tapestry.apache.org
An
Tapestry users
users@tapestry.apache.org
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
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 users@tapestry.apache.org
An
Tapestry users users@tapestry.apache.org
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,
ConfigurationAliasContribution 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
users@tapestry.apache.org
An
Tapestry users
users@tapestry.apache.org
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
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
users@tapestry.apache.org
An
Tapestry users
users@tapestry.apache.org
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,
ConfigurationAliasContribution 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
users@tapestry.apache.org
An
Tapestry users
users@tapestry.apache.org
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
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: 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]
T5 Decoupling a Template From its Component Class
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]
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
