But this shouldn't be a problem, there are major differences between the
two the only thing similar is the page extension, but if I change the
page extension then I have duplicate pages and configure my entire
application to use different extensions, sometimes the same page is
called from two or three different services (external, direct, page etc)
so why should i change the extensions just for the sake of an encoder...
I have also tried to implement custom encoders, even subclass the page
service, but I couldn't get it to work and ran into similar problems.
>if you put both extionsons to html then both encoders think that the
rendering page is pointed to them.
But the encoder logic check for the matching service ??
Peter
Peter Schröder wrote:
i dont think that it is a good thing to name different services with same
extension.
look into the example of writing your own encoder and you will see where the
problem come from:
if you put both extionsons to html then both encoders think that the rendering page is pointed to them.
-----Ursprüngliche Nachricht-----
Von: Peter Stavrinides [mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch, 17. Januar 2007 14:56
An: Tapestry Mailing List
Betreff: Friendly URL's and service encoders
Hi everyone
I am having some trouble with friendly URL's. Getting them to work is
not the problem, but getting two page service encoders to work together
seems unlikely. Maybe there is a better way to do this... I don't know.
I basically want an encoder that will generate friendly URL's for html
pages that use either the external or page services (PageLink of
ExternalLink components).
This is what my encoders look like, both work ok but when used in
tandem, they fight.
<contribution configuration-id="tapestry.url.ServiceEncoders">
<page-service-encoder id="external" extension="html"
service="external"/>
<page-service-encoder id="page" extension="html" service="page"/>
</contribution>
Any ideas?
Peter
--
Peter Stavrinides
Albourne Partners (Cyprus) Ltd
Tel: +357 22 750652
If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Please visit http://www.albourne.com/email.html for important additional terms relating to this e-mail.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]