That won't help, the sfFileCache is fine for what I need. The problem is the actual sfCache instances is called to test for, retrieve or store content for a certain cache key. It is sfViewCacheManager that calculates the cache key, so anything I do in the sfCache implementation is beyond the point of possibility to alter the cache key generation.
On 7 mei, 17:43, "Thomas Rabaix" <[EMAIL PROTECTED]> wrote: > Hello, > > The sfViewCacheManager uses by default the sfFileCache, you can change > this value in the factory.ym. > > what you might do is to create our own cache file : > dvCultureDateFileCache which extends sfFileCache. you can then create > a specific file for the request. > > I havn't test it, just read the code > > Thomas > > On Wed, May 7, 2008 at 5:24 PM, Dennis Verspuij > > > > > > <[EMAIL PROTECTED]> wrote: > > > Hi Thomas, yes I did try to add the parameters to the sfRequest > > instance parameters in a custom filter. But this results in sfRouting > > complain that the current route cannot be found when it has to > > generate the interal uri of the request. That is off course because > > the parameters do not exist in the various routes I have configured. > > Some of the routes will work because they have * in the path, but for > > example the homepage doesn't. > > > Still this would only work when caching actions, but not for > > components and partials because they receive parameters in the > > get_component / get_partial calls. > > > I really want to hook into how sfViewCacheManager creates cache keys. > > Any ideas? > > > On 7 mei, 14:37, "Thomas Rabaix" <[EMAIL PROTECTED]> wrote: > > > Hello, > > > > Have you try to use a filter to append new params to the request ? > > > > Thomas > > > > On Tue, May 6, 2008 at 11:18 PM, Dennis Verspuij > > > > <[EMAIL PROTECTED]> wrote: > > > > > The sfViewCacheManager creates cache keys based on parameters that > > > > appear in the request. Is there any way to apply some custom > > > > parameters to each cached action, component and/or partial, without > > > > messing with the internal uri? > > > > > For example, I keep currently selected language and time zone for a > > > > visitor in the user session, so these values are not included as > > > > parameters in each request. But off course I want Symfony to generate > > > > and cache content for each combination of language and time zone > > > > differently. > > > > > My findings: > > > > If I would add the language and timezone to the sfRequest parameters, > > > > sfRouting will complain while generating the internal URI because my > > > > routes do not include these parameters. > > > > So that is not an option. It also does not appear to be possible to > > > > extend sfViewCacheManager, because sfViewCacheManager is hardcoded in > > > > sfFactoryConfigHandler and not overridable with a value in > > > > factories.yml. I wonder why that is? Even if I could extend it I would > > > > have to override each method that accepts an internal uri argument, in > > > > order to secretly add my language and timezone parameters to it. > > > > Finally http vary headers did also not help. > > > > > So I am stuck here, the cache mechanism looks very flexible in where > > > > to cache content (file, memory, database, etc.) by setting a custom > > > > view_cache class. But not flexible in "how" to determine cache keys. I > > > > surely hope someone can help me out? > > > > -- > > > Thomas Rabaix > > > > Internet Consultant- Tekst uit oorspronkelijk bericht niet weergeven - > > > > - Tekst uit oorspronkelijk bericht weergeven - > > -- > Thomas Rabaix > > Internet Consultant- Tekst uit oorspronkelijk bericht niet weergeven - > > - Tekst uit oorspronkelijk bericht weergeven - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~----------~----~----~----~------~----~------~--~---
