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

FormResource.lookup(LookupState...

From: Anselm Baird_Smith <abaird@www43.inria.fr>
Date: Mon, 25 Nov 1996 12:40:55 +0100 (MET)
Message-Id: <199611251140.MAA21538@www43.inria.fr>
To: Joel.Crisp@bristol.ac.uk
Cc: www-jigsaw@w3.org
Joel Crisp writes:
 > 
 > Hi
 > 
 > I've noticed that this resource consumes path name elements even if it
 > fails to find a card resource with the requested name.
 > 
 > This makes it harder for sub-classes to mix cards and other resources
 > under the path of a FormResource, e.g. I have a database which has a
 > set of cards for doing new searches. entering new records etc. It also
 > is a ContainerResource similar to DirectoryResource for the historical
 > log of searches made and their results - which are non-card resources
 > held by the database resource.
 > 
 > Is it possible to ensure that lookup functions only consume path
 > elements if they are successful at looking up ?

Correct, here is a fix, that will be included in next release
(unchecked yet, but should work):

    /**
     * Lookup an sub resource.
     * Each form card makes its own resource, that's why the 
     * <code>lookup</code> method for this resource is special.
     * @param ls The current lookup state.
     * @return An HTTPResource matching the name to lookup, or
     *    <strong>null</strong> if none was found.
     */

    public boolean lookup (LookupState ls, LookupResult lr) 
	throws HTTPException
    {
	if ( super.lookup(ls, lr) )
	    return true;
	String name = ls.peekNextComponent() ;
	for (int i = 0 ; i < vcards.size() ; i++) {
	    FormCardResource card = (FormCardResource) vcards.elementAt(i) ;
	    if ( card.getName().equals(name) ) {
		// Remove found component from lookup state
		ls.getNextComponent();
		// Setup lookup result:
		lr.setTarget(card);
		return card.lookup(ls, lr);
	    }
	} 
	lr.setTarget(null);
	return false;
    }

Let me know if this solves your problem,
Anselm.
Received on Monday, 25 November 1996 06:41:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 9 April 2012 12:13:25 GMT