You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Mark Lundquist <ml...@comcast.net> on 2005/09/24 06:55:02 UTC
VariableResolver in I18nTransformer
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—
I18nTransformer is driving me crazy
Posted by Mark Lundquist <ml...@wrinkledog.com>.
Hi,
The I18nTransformer is giving me fits. When I change the contents of a
message catalogue, the changes don't take affect unless I restart
Cocoon. This is slowing my development to a crawl. I have
<cache-at-startup> set to false.
I thought that requesting the root resource with '?cocoon-reload=true'
was supposed to reload the whole sitemap configuration... does that not
work in 2.1.7?
Help! What do I need to do to get back into "rapid development" mode
here?!?! :-)
thanks,
—ml—
Re: I18nTransformer is driving me crazy
Posted by Nouguier Olivier <ol...@wanadoo.fr>.
hi all,
I built my own i18n transformer based on properties files with caching
option.
It's beta code, but if somes are interested ...
On Sat, 2005-09-24 at 12:38 -0600, Jason Johnston wrote:
> Mark Lundquist wrote:
> > The I18nTransformer is giving me fits. When I change the contents of a
> > message catalogue, the changes don't take affect unless I restart
> > Cocoon. This is slowing my development to a crawl. I have
> > <cache-at-startup> set to false.
> >
> > Help! What do I need to do to get back into "rapid development" mode
> > here?!?! :-)
>
> Several of us are seeing this problem. See the thread "Two I18N
> Problems" from 2005-09-20. No solutions yet.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
> ---------------------------------------------------------------------------------------
> Wanadoo vous informe que cet e-mail a ete controle par l'anti-virus mail.
> Aucun virus connu a ce jour par nos services n'a ete detecte.
>
>
>
http://www.orcades.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: I18nTransformer is driving me crazy
Posted by Jason Johnston <co...@lojjic.net>.
Mark Lundquist wrote:
> The I18nTransformer is giving me fits. When I change the contents of a
> message catalogue, the changes don't take affect unless I restart
> Cocoon. This is slowing my development to a crawl. I have
> <cache-at-startup> set to false.
>
> Help! What do I need to do to get back into "rapid development" mode
> here?!?! :-)
Several of us are seeing this problem. See the thread "Two I18N
Problems" from 2005-09-20. No solutions yet.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
I18nTransformer is driving me crazy
Posted by Mark Lundquist <ml...@wrinkledog.com>.
[I originally posted this to the dev list by mistake... moving to the
users' list]
-=-=-=-=-=-=-=-=-=-=-=
Hi,
The I18nTransformer is giving me fits. When I change the contents of a
message catalogue, the changes don't take affect unless I restart
Cocoon. This is slowing my development to a crawl. I have
<cache-at-startup> set to false.
Help! What do I need to do to get back into "rapid development" mode
here?!?! :-)
thanks,
—ml—
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: VariableResolver in I18nTransformer
Posted by Mark Lundquist <ml...@wrinkledog.com>.
On Sep 24, 2005, at 12:05 AM, Ralph Goers wrote:
> Looking at the code it certainly doesn't look like it.
>
> XMLResourceBundleFactory uses a regular source resolver, not the
> variable source resolver.
Hmm, I didn't know there even was a variable source resolver... anyway,
take a look 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 it isn't working for me.
> This is a problem for me as well. 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. That fix will certainly cause my sites to fail so we
> will have to put a variable into the path to allow it to work again.
> So it seems that XMLResourceBundleFactory will need to be modified to
> use the variable resolver.
>
> Ralph
>
> Mark Lundquist wrote:
>
>> 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—
>>
>
Re: VariableResolver in I18nTransformer
Posted by Ralph Goers <Ra...@dslextreme.com>.
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
Re: VariableResolver in I18nTransformer
Posted by Joerg Heinicke <jo...@gmx.de>.
Hello Ralph,
On 26.09.2005 01:17, Ralph Goers wrote:
> In fact, after looking at
> the code again I think the statement I made below is wrong. I'm pretty
> sure that I won't be affected the way I anticipated.
nice to hear. I also could not imagine how fix 2 should have influence
on pure usage (in contrary to extension) of i18n. It should have been
only an internal change making the bundle unmodifiable, which allowed to
simplify the interaction with the bundle factory.
> My I18n configuration looks like:
>
> <catalogues default="banking">
> <catalogue id="banking" name="banking">
> <location>prefs://BCI18nCatalogs/</location>
> <location>prefs://I18nCatalogs/</location>
> </catalogue>
> </catalogues>
Fix 1 was about always getting the same catalogue for a first location
(here "prefs://BCI18nCatalogs/"), independent from the latter locations.
I fixed this but broke something else, what Vadim fixed between fix 1 and 2.
> Looking at the code,
> it is still using the system id as the cache key so I shouldn't
> experience any problems. I was anticipating that I would be forced to
> put a varaible into the location to represent the bank name, but that
> doesn't appear to be the case.
No, it still should work.
> I guess the issue is, some users don't seem to be able to reload their
> catalogs. Now, when I first started working with the I18nTransformer it
> didn't allow catalog reloading. That appears to have been addressed in
> January 2004. However, the mails I am seeing here indicate that it is
> not working, at least in some circumstances.
I never really tested it if it works for our application.
Jörg
Re: VariableResolver in I18nTransformer
Posted by Ralph Goers <Ra...@dslextreme.com>.
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 have to change my configuration. In fact, after looking at
the code again I think the statement I made below is wrong. I'm pretty
sure that I won't be affected the way I anticipated.
My I18n configuration looks like:
<catalogues default="banking">
<catalogue id="banking" name="banking">
<location>prefs://BCI18nCatalogs/</location>
<location>prefs://I18nCatalogs/</location>
</catalogue>
</catalogues>
Obviously, prefs is my own protocol. When BCI18nCatalogs is resolved
the prefs resolver determines which bank the current request is for and
locates the catalog for them. It generates a system id that includes the
bank's name, so each bank should be cached independently. So each bank
has its own catalog followed by a common catalog. Looking at the code,
it is still using the system id as the cache key so I shouldn't
experience any problems. I was anticipating that I would be forced to
put a varaible into the location to represent the bank name, but that
doesn't appear to be the case.
I guess the issue is, some users don't seem to be able to reload their
catalogs. Now, when I first started working with the I18nTransformer it
didn't allow catalog reloading. That appears to have been addressed in
January 2004. However, the mails I am seeing here indicate that it is
not working, at least in some circumstances.
Ralph
Joerg Heinicke wrote:
> 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. That fix will
>> certainly cause my sites to fail so we will have to put a variable
>> into the path to allow it to work again.
>
>
> I guess you mean either the caching of multiple locations [1] or the
> unmodifiable bundles [2]? In which way does it break your sites? Why
> did you not cry out earlier?
>
> Jörg
>
> [1] http://marc.theaimsgroup.com/?l=xml-cocoon-cvs&m=110702874021546&w=4
> [2] http://marc.theaimsgroup.com/?l=xml-cocoon-cvs&m=111999955919291&w=4
Re: VariableResolver in I18nTransformer
Posted by Joerg Heinicke <jo...@gmx.de>.
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. That fix will certainly
> cause my sites to fail so we will have to put a variable into the path
> to allow it to work again.
I guess you mean either the caching of multiple locations [1] or the
unmodifiable bundles [2]? In which way does it break your sites? Why did
you not cry out earlier?
Jörg
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-cvs&m=110702874021546&w=4
[2] http://marc.theaimsgroup.com/?l=xml-cocoon-cvs&m=111999955919291&w=4
Re: VariableResolver in I18nTransformer
Posted by Ralph Goers <Ra...@dslextreme.com>.
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 custom protocol which
internally derives the path based upon the website being accessed even
though the uri is the same for all websites. That fix will certainly
cause my sites to fail so we will have to put a variable into the path
to allow it to work again. So it seems that XMLResourceBundleFactory
will need to be modified to use the variable resolver.
Ralph
Mark Lundquist wrote:
> 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—
>