W3C home > Mailing lists > Public > www-jigsaw@w3.org > November to December 1996

Re: Unpickling ATTR_URL

From: <Joel.Crisp@bristol.ac.uk>
Date: Tue, 3 Dec 1996 11:47:11 +0000 (GMT)
Message-Id: <9612031134.AA21863@www.ets.bris.ac.uk>
To: www-jigsaw@w3.org

On  3 Dec, Anselm Baird_Smith wrote:
> Joel Crisp writes:
>  > 
>  > Hi
>  > 
>  > Thanks for the clarification. I understand now. ;-)
>  > 
>  > It seems to me that DirectoryResource is a good one to sub-class, but
>  > it has a little too much in it which is specific to directory/file type
>  > resourcing. Maybe we could do with a class (which is abstract?)
>  > implementing the heirachical resource mamagement but without the
>  > directory specific orientation.
>  > 
>  > Creating my new resources, I've had to cut and paste large chunks of
>  > directory resource which are essentially unchanged. In my particular
>  > case this would not help me - I need to inherit from FormResource as
>  > well, but I can think of several cases where it would be useful.
>  > 
>  > If other people want this I', quite happy to make the changes
> That's already on my todo, I was looking at something like:
> ContainerResource
> StoreContainerResource (a container that manages a store)
> (?) TemplateContainerResource
> (?) ??
> DirectoryResource 
> Would this help ? the bug split would be between ContainerResource and
> StoreContainerResource (or whatever the name ends up being).
> Anselm.
Hmmm. This is certainly the sort of direction I was thinking in.
However, it is complicated by the requirements which mean I have to deal
with FormResource as well. 

There are two ways in which I see to try to handle this (thinking aloud
 !) :

Maybe we need an independent object which can be refered to from inside
a resource, and then a set of one line functions to transfer control
from an implementable interface to the referred object. Somewhat like
this (in pseudocode) :

class MyResource extends SoemthingResource implements
ResourceStoreHolder {

    public lookup(String name) { return(theStore.lookup(name)); }


Alternatively, we could make the form code helper functions static(?)
in a helper class which then can be trivally invoked from the get/put
methods. This may be a simpler solution.
Much as I hate to say it, this is one of the instances where multiple
inheritance might be useful ! ;-(

At the same time, maybe the plephora of lookup functions could be
streamlined a bit. 

( Aside : I've been having fun with URLs containing encoded spaces and
the lookup functions - it seems that the URL is decoded before a lookup
is attemped - can resourceStore handle names with spaces/other weird
charracters in ? )

Joel.Crisp@bris.ac.uk | ets-webmaster@bris.ac.uk  | "I remember Babylon" -
Software Engineer, Institute of Learning and      |        Arthur C Clarke
Research Technology, University of Bristol, UK    |
http://www.ets.bris.ac.uk/                        |
Received on Tuesday, 3 December 1996 06:51:59 UTC

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