Hi Vadim,
sorry I am little bit confused today by the heat in this office.
Now I understand your problem. Quick thinking, I would say that
the generated key not only contains the parameter names but
the parameter values as well. I think this is ok, as you could
say that the file name of the xsl file is a paramter named
file with the value of the real file name.
Then all requests for that pipeline with exactly the same
parameter set will lead to the same key and to the same
cached content.
I assume this is the way, I should work. Right?
Carsten
Open Source Group sunShine - b:Integrated
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de mailto: [EMAIL PROTECTED]
================================================================
> Vadim Gritsenko wrote:
>
> Carsten, Giacomo,
>
> I don't know what to say... But let's look at an example.
> Suppose you have an XML data and an XSLT to present it.
> Obviously, you might have at least two variants to present this data,
> and user chooses one he likes. From URL point of view, it might look like
> http://host/cocoon/data?view=1 and http://host/cocoon/data?view=2.
> With newly changes TraxTransformer, cache would work ONLY if your
> site have ONE and ONLY ONE customer, or ALL customers have SAME
> preferences.
> But this is not real situation, all people are different...
>
> So, to make cache work, you FORCED to use
> http://host/cocoon/data/view-1 and http://host/cocoon/data/view-2
> which obviously means you have to rewrite your stylesheets and sitemap.
>
> This was highly simplified example; in real app you would have 4-5 or more
> parameters to control presentation. Take a look at least at slides example
> in Cocoon2. Before, it was perfectly cacheable. And now - not.
>
> I do think that newly introduced behaviour is might be desirable
> in some cases,
> but I also want to have an opportunity to use previous one.
> I do propose to introduce new parameter for TraxTransformer,
> something like
> _useParametersValues. Other solution mught be to write derived
> transformer
> which would do this. Let me know which way is preferred.
>
> PS: I have built my site around content aggregation & caching,
> I use computational stylesheets and I use cache extensively to
> store computed results. So far, I managed to keep request time
> under 300ms for requests which are with cache turned off might
> easily take up to 30sec.
>
> Thanks,
> Vadim
>
>
> > Giacomo Pati wrote:
> >
> > On Thu, 5 Jul 2001, Vadim Gritsenko wrote:
> >
> > > Giacomo,
> > >
> > > Previously it was possible to cache results for request
> > > such as "page?param=value1" and "page?param=value2"
> > > independently.
> > >
> > > This change would effectively disable cache for such
> > > kind of requests. :(
> > >
> > > PS:
> > > Previously key was generated from string like:
> > > "systemid{param=value1}",
> > > now it looks like:
> > > "systemidparam"
> >
> > Well, I thought this is the right way to specify keys. Maybe Carsten can
> > enlight us more. Isn't it true that the genKey method should use the
> > NAMEs to build the key whereas the validate method takes the values into
> > account.
> >
> Here is the light....
>
> No, honestly, I think you are right:
>
> The key identifies all input used by the transformer apart from the sax
> stream,
> so I think the key should contain also the parameter names (if
> they are used
> by the transformer).
> Then the validity objects validate the values of the parameters.
>
> Carsten
>
> </skip>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
