cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niels van Kampenhout <n.vankampenh...@hippo.nl>
Subject Re: Caching jx *without* flow
Date Tue, 19 Sep 2006 09:43:00 GMT
Leszek Gawron wrote:
> Niels van Kampenhout wrote:
>> Leszek Gawron wrote:
>>> The only thing that's missing from HippoJXTemplateGenerator.java 
>>> functionality is the ability to exclude some parameters from cache 
>>> key. Anyway this looks like FS from the start:
>>
>> What do you mean by FS? False Security?
> Flexibility Syndrome :)

Ah, ok! The lists of internet abbreviations I found through Google 
actually all said it meant "For Sale" :-)

>>
>>>  - if template makes use of all cocoon parameters they should be a part
>>>    of the cache key,
>>>  - if not - you shouldn't pass them instead of excluding.
>>>
>>> Please comment.
>>
>> These two statements are true, and exactly satisfy our requirements. 
>> You may have other requirements, though.
> I was refering to jx:includeKey and jx:excludeKey parameters in your 
> generator. Why do you use it at all?

I see what you mean now. I don't think we ever use those parameters, and 
thinking about it, they do not make sense to me either. If you exclude a 
sitemap parameter from the cache key, either you get a false cache 
response or the sitemap parameter was not used in the template anyway.

>> What matters to me is this: in our projects we mainly use JXTG and 
>> XSLT, and (as far as I can see from a user perspective) with our 
>> solution the formation of the cache key is consistent between the two 
>> (cocoon parameters == cache key). This is a big plus in the fragmented 
>> world of Cocoon technologies.
> I like the analogy. In order to fully utilise it we would have to go 
> further in similarities: JTGX object model in this case should be 
> constructed only with sitemap parameters.
> 
> automatic cache key from sitemap parameters + small object model = full 
> XSLT analogy. We could try this.

And the cream on the cake would be to have the same expression language 
in templates and XSLTs. I keep mixing those up....

>> Bottom line: we prefer different solutions and are both happy with 
>> them. Good thing we live in a free world ;-)
> Agreed :)

Good, back to work then! :-)

Regards,
Niels


Mime
View raw message