cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cédric Vidal <d...@atilla.org>
Subject RE : DeltaTimeCacheValidity deprecated ?
Date Sat, 16 Aug 2003 22:47:12 GMT
Selon Geoff Howard <cocoon@leverageweb.com>:

> Cédric Vidal wrote:
> > Hi,
> > 
> > I'm new to this list, so please excuse me if I where to ask a silly
or
> > already answered question.
> 
> Welcome to the list.  A great resource is the mailing list archives -
> they're linked from the Cocoon site and documentation, but you can
> find them at http://marc.theaimsgroup.com along with other spots.

Thanks for your welcome :o)


> > I'm in the process of upgrading my cocoon 2.0.4 app to cocoon 2.1
and I
> > have a problem with new Validity objects.
> > 
> > I want one of my XSP pages to be valid for 1 minute. The object
> > DeltaTimeCacheValidity which I used in cocoon 2.0.4 now seems to be
> > deprecated in cocoon 2.1. I looked in the repository and saw that
the
> > CacheValidity contract had been replaced by Excalibur's
SourceValidity
> > contract.
> 
> Actually, the classes really moved to the Excalibur project so others 
> could use them.  Converting in this case is really easy.
> First of all, DeltaTimeCacheValidity defined three constructors:
>    DeltaTimeCacheValidity(long minutes)
>    DeltaTimeCacheValidity(long minutes, long seconds)
>    DeltaTimeCacheValidity(long minutes, long seconds, long
milliseconds)
> 
> its successor
org.apache.excalibur.source.impl.validity.ExpiresValidity 
> defines just one:
>    ExpiresValidity(long milliseconds)
> 
> Next, the method
>    public long generateKey()
> is now
>    public Serializable getKey()
> 
> and
>    public CacheValidity generateValidity()
> is now
>    public org.apache.excalibur.source.SourceValidity getValidity()
> 
> That's it.  Let me know if you need more help implementing the change 
> but hopefully it looks pretty trivial to you.  The example of the 
> cacheable xsp uses another option where a CacheValidity to 
> SourceValidity adaptor/factory is used.  It's just as easy to make the

> change correctly though, and I think the xsp should get changed to 
> reflect the new method without the complication it uses.

Thanks for the feedback, your confirming my thoughts, but what strikes
me is that the given class ExpiresValidity has been removed explicitly
from the repository, and it doesn't seem as if it was to move it to some
other place, please correct me if I'm wrong.

So I'm wondering what may be the reason to take out from the
distribution such a useful class (at least, it is to me ;), more
especially as there must be quite a lot of people depending on the
former DeltaTimeCacheValidity.

One such reason, of course, would be if there was some other more
"right" way of achieving that caching purpose by the mean for example of
some dedicated transformer or action. Please again, I would be grateful
if you could tell me if it is so.

I also tried an alternative: my XSP page is basically an esql page, so I
tried to fill my need by using the SQLTransformer which I hadn't tried
before. I managed to get it working, it's pretty straightforward, but it
doesn't seem possible to specify the validity, so basically, I'm stuck
with the same problem as before. And this leads to the discussion led in
thread:
http://marc.theaimsgroup.com/?t=106055805900001&r=1&w=2
I look forward seeing the solution of that issue.

> Well, the quickest solution is to not exclude them - if you just want
to 
> move on right away.  But it'll be much better to just make this simple

> update.

That's for sure, and I agree with you, I prefer to update but that case
is pretty weird.

I guess I might just checkout the last available version of
ExpiresValidity, and stick with it.

Thanks again for the answer.

Cédric




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message