Re: Unpickling ATTR_URL

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 {
    GenericResourceStore
    theStore=GenericResourceStore.getmystore("MyResource");

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

  etc.   
}

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
-- 
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