Re: CaheValidity & toString()

[Vadim Gritsenko]

Stephen Ng wrote:

Okay I understand everything you say, but I still think the
ContentAggregator code has a problem.

It's not second one, it's *the* *same* object. Equal keys == same object. See cacheable.xsp to get an idea, it shows how with the help of a single XSP you can create multiple objects (with different keys). In cacheable.xsp, every different value of the request parameter 'param' will create different object (in the cache).
...
I think you had confusion here. Main point is:
Key identfies object,
Validity represents *status* of this object (changed - need to be re-generated / not changed - can serve from cache).

Thus, to create several objects, simply generate different keys.

I understand the code in cacheable.xsp; but even if cacheable.xsp has
multiple keys, those keys are not taken into account when cacheable.xsp
is put into an aggregation--ContentAggregator will always generate the
same key, no matter what cacheable.xsp's generateKey() function is!

I see.

(Because cacheable.xsp's generateKey() is totally ignored by
ContentAggregator's generateKey()).  This is wrong.

It's not desirable in some situations, yes, but it's not completely wrong - it depends on semantics of content aggregator... But right now I think that you are right, and this is wrong, but this should be given some more thoughts.

My change uses the (hash of the) xsp's validityObject instead of its key
as a part of ContentAggregator's generateKey()--this is not so good, but
I don't know how to get to the key from a SitemapSource.

Not possible ATM...


PS In the meantime, workaround is to use such System IDs (cocoon:// URLs) that have same information as a key, because System IDs are not ignored.

Vadim

Still, I
believe that the hash of the validityObject is better than what is there
now!

--Steve

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]