W3C home > Mailing lists > Public > www-jigsaw@w3.org > May to June 1997

Re: Two problems.

From: Alexandre Rafalovitch <arafalov@socs.uts.EDU.AU>
Date: Thu, 12 Jun 1997 12:54:37 +1000 (EST)
To: Jigsaw mailing list <www-jigsaw@w3.org>
Message-ID: <Pine.SOL.3.95.970612124839.11146A-100000@siili>
On Wed, 11 Jun 1997, Anselm Baird_Smith wrote:

> Alexandre Rafalovitch writes:

>  > 2. HttpResource.delete calls parent.markModified() before it calls
>  > super.delete. As a result, any container class overriding markModified
>  > would not know what happens when resourse is requested to be deleted as
>  > the resource is still there. I do not see why is it so. I have a current
>  > workaround (basically mark that something changed and deal with it on
>  > request) which works well, but I would like to understand the logic of
>  > current implementation.
> I am not sure I understand. As far as I recall, the markModified trick
> is to enable accurate container listing (in the case that listing get
> cached)

Ok, here is the sequence I wanted to use (as I have said the other way was
just as nice, but I just want to know if I erred in my understanding)

1. Container keeps cached info about its children, which it updates when
markModified gets called. Let's say container knows it has 3 children.
2. I call up the editor and choose delete on a child resource.
3. delete method in the child calls parent.markModified.
4. parent looks around and try to recache the info about its children. It
sees three children (as before) and has no idea what has changed.
5. after markModified returns, child calls super.delete() which removes it
from the store, etc.
6. delete is successfull, but parent container has a reference that is not

I thought it would be reasonable to put step 5 before step 3 by exchanging
the order functions are called.

What I did instead was to remove cached info in markModified and that
forces a rebuild of it on next service call. 

Hope it helps,
Received on Wednesday, 11 June 1997 22:54:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:31 UTC