Re: getNextComponent and peekNextComponent

Hi

On 12 Mar, Anselm Baird_Smith wrote:
> Joel Crisp writes:
>  > Hi
>  > 
>  > It looks to me as if there is some confusion as the behaviour of
>  > resources implementing "lookup" on failure - some seem to consume the
>  > path with getNextComponent -then if they have been called from a de
>  > rived class via super and fail, the derived class no longer has access
>  > to the relevent information. StoreContainer seems to be one of the
>  > offenders.
> 
> Do you mean StoreContainer should call getNextComponent only *after*
> making sure lookup(String name) did succeed ?

I think so. I must confess to being a little confused as to what exactly
I mean. Maybe getNextComponent should always be a 'peek' rather than a
consumer, using a component pointer in the LookupState ? Would
this make all the problems go away ?

> 
>  > Personally, I believe that changing getNextComponent to
>  > peekNextComponent would be more efficent - note that you have to
>  > consume the path if there is a resource found.
> 
> If I understand correctly the rule would be for ContainerResource
> sub-class to consume part of the path only if lookup succeed, and
> otherwise, to leave the LookupState as it was (before lookup was
> called)
> 
>  > Hmmm. Having said that, if a resource further down the line doesn't
>  > find it, the path is consumed anyway. Maybe the whole method needs a
>  > re-think and/or some better documentation on the intended behaviour.
> 
> I would tend to agree with that, and would like to clear it up before
> next release.

This is all quite critical to my database stuff, as it synthesises
resources on the fly for accessed records, which, because they are
synthesised completely from the record, do not ever need to add
themselves to a resource store. ( If the admin user tweaks the resource
mirroring the record, then it knows it has to store itself and does
so..)
> 
> Anselm.

Joel
-- 
Joel.Crisp@bris.ac.uk | ets-webmaster@bris.ac.uk  | "I remember Babylon" -
Software Engineer, Institute for Learning and     |        Arthur C Clarke
Research Technology, University of Bristol, UK    |
http://www.ets.bris.ac.uk/                        |

Received on Wednesday, 12 March 1997 07:02:23 UTC