cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <Ralph.Go...@dslextreme.com>
Subject Re: VariableResolver in I18nTransformer
Date Sun, 25 Sep 2005 23:17:05 GMT
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


Mime
View raw message