On 24.09.2005 09:05, Ralph Goers wrote:
XMLResourceBundleFactory was modified recently to fix caching. I am
currently using a locations that contain a custom protocol which
internally derives the path based upon the website being accessed even
though the uri is the same for all websites.
I believe it was item [2] that I suspected was going to be an issue for
me. Mind you, I haven't tested the I18nTransformer in a while so I
don't actually know if it causes me any problems. That, plus the way in
which I am resolving catalogs is why I didn't mention it - I just
assumed I'd
You know, we should proably embelish I18nTransformerTestCase to verify
some of these things. Maybe I can do that in the next couple of days
and see what happens.
Ralph
Joerg Heinicke wrote:
I never really tested it if it works for our application.
Jörg
Looking at the code it certainly doesn't look like it.
XMLResourceBundleFactory uses a regular source resolver, not the
variable source resolver. This is a problem for me as well.
XMLResourceBundleFactory was modified recently to fix caching. I am
currently using a locations that contain a
in I18nTransformer itself — the name and location values
are already processed through a VariableResolver before they are passed
off to the bundle factory. So that should be working, whatever that
means :-). I think I just don't understand the semantics of sitemap
variables well enough to figure out why
Hi,
I have a sitemap resource that calls an I18nTransformer. Within a
catalog entry of the transformer configuration, can I reference a
parameter of the resource, like
catalogue id=whatever name=messages location={path}
??
thx,
—ml—
Sylvain Wallez wrote:
That's a good point. Having to pass the service manager and object model
around is a pain and may justify componentization.
However, that component would be declared in cocoon.xconf (or even
cocoon.roles) when it may need components defined locally in the current
Ralph Goers wrote:
I'm a little confused. In treeprocessor we have
class NOPVariableResolver
class PreparedVariableResolver
class VariableResolver
class VariableResolverFactory
In the portal block we have
class DefaultVariableResolverFactory
class
Sylvain Wallez schrieb:
Ralph Goers wrote:
I'm a little confused. In treeprocessor we have
class NOPVariableResolver
class PreparedVariableResolver
class VariableResolver
class VariableResolverFactory
In the portal block we have
class
Carsten Ziegeler wrote:
Sylvain Wallez schrieb:
Ralph Goers wrote:
I'm a little confused. In treeprocessor we have
class NOPVariableResolver
class PreparedVariableResolver
class VariableResolver
class VariableResolverFactory
In the portal block we have
class
If it is an older copy then what does moving the code from the portal
to the core mean? Does the core already contain all the same
functionality and the portal version should just be removed? I'll be
happy to do it if I know what to do.
Ralph
Carsten Ziegeler wrote:
Yepp, it's an older
Sylvain Wallez wrote:
Sure, it totally makes sense. Now I'm wondering if we really need this
to be components. Will there ever be more than one implementation?
The current implementation in the treeprocessor is not usable outside
the treeprocessor (at least it wasn't at the time the portal
OK. It should be easy enough to test with the portal sample site.
Ralph
Carsten Ziegeler wrote:
The core is the most recent version. The only thing that has to be
done is remove the code from the portal and make the core version usable
and use it then in the portal (or whereever).
Carsten
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Sure, it totally makes sense. Now I'm wondering if we really need this
to be components. Will there ever be more than one implementation?
The current implementation in the treeprocessor is not usable outside
the treeprocessor (at least
I'm a little confused. In treeprocessor we have
class NOPVariableResolver
class PreparedVariableResolver
class VariableResolver
class VariableResolverFactory
In the portal block we have
class DefaultVariableResolverFactory
class NOPVariableResolver
class
Thanks!
Carsten
-Original Message-
From: Upayavira [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 06, 2004 9:36 PM
To: [EMAIL PROTECTED]
Subject: Re: [BUG] NPE in VariableResolver
Carsten Ziegeler wrote:
I just tried some examples for the upcomming release and the input
Seems like a good change to me.
Carsten
-Original Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Jorg Heymans
Sent: Thursday, May 06, 2004 11:20 PM
To: [EMAIL PROTECTED]
Subject: Re: [BUG] NPE in VariableResolver
Coincidentally, i was just clicking through the HEAD
] On Behalf Of Jorg Heymans
Sent: Thursday, May 06, 2004 11:20 PM
To: [EMAIL PROTECTED]
Subject: Re: [BUG] NPE in VariableResolver
Coincidentally, i was just clicking through the HEAD samples
to see if there were any broken links i could (easily) fix. (see also
http://issues.apache.org/bugzilla
I just tried some examples for the upcomming release
and the input module sample for baseLink
http://localhost:/samples/modules/baselink.html
throws an NPE in the variable resolver.
Is this due to the variable resolver changes (nested variables)?
Carsten
Carsten Ziegeler
Open Source
Coincidentally, i was just clicking through the HEAD samples to see if
there were any broken links i could (easily) fix. (see also
http://issues.apache.org/bugzilla/show_bug.cgi?id=28810)
The baselink module sitemap should be patched to something more
appropriate like inlined patch below.
20 matches
Mail list logo
