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]
