Re: Clarification on the indexer

>
>One thing I could do (let me know if this would help you), is the
>following: make the ResourceIndexer an interface, and make the current
>resource indexer a SampleResourceIndexer, implementing that
>interface. I would then add a new property to Jigsaw in order to know
>what indexer class it should use as an indexer.
>
>If this makes sense (BTW to anyone) then the ResourceIndexer interface
>would probably look like:
>
>public interface ResourceIndexer {
>     public Resource createDirectoryResource(File directory
>                                             , String name
>                                             , Hashtable defs);
>
>     public Resource createFileResource(File file
>                                        , String name
>                                        , Hashtable defs);
>
>}
>
>The File parameter is the "object" to be indexed (it has to be refered
>to by something, in this case a File instance).
>The name is the identifier for the resource to be created (can be
>different from the file's name)
>The defs hashtable is a set of default attribute values for the
>resource to be created.
>
>If this would be of any use to anyone let me know. Note that you could
>implement such an interface, and "chain" indexer together. Say you
>implement the FancyResourceIndexer, if it doesn't know how to create a
>resource, it could forward the call to a "default"
>SampleResourceIndexer instance.

YES!!! This would fit very nicely into a project we're working on, where we
would like to use the indexer to create "virtual directories" of
information that might not exist on the server at all.  Instead, there are
repository files (like .jigidx files) containing metadata, which is used to
obtain/synthesize/present the information on the fly when it is accessed.
By using a different indexer implementation, we could better integrate the
creation of these metadata repositories into the Jigsaw architecture.

What if, instead of CreateFileResource(), there were something more
general, like CreateHTTPResource() or CreateContainerResource(), or
something of that ilk?

Our "virtual directories" are not instances of DirectoryResource, nor are
our leaf resources instances of FileResource.  Instead, we are using more
abstract definitions specific to our architecture.  Our
VirtualContainerResource and LeafResource classes are, in fact, descended
from FilteredResource.  The reason for this is that DirectoryResource is
currently written in such a way that it must contain files/directories, and
our "virtual containers" contain more abstract entities.



+---------------------+-------------------------+---------------------+
|    Dave Makower     |    davemak@pencom.com   |   WWW Specialist    |
+---------------------+-------------------------+---------------------+
|     Co-author of "Java Programming Basics" (Henry Holt/MIS:Press)   |
|                 http://www.pencom.com/javabasics/                   |
+----------------------------------+----------------------------------+
|   Pencom Web Works               |   (212) 513-7777   voice         |
|   Pencom Systems Inc.            |   (212) 513-1975   fax           |
|   40 Fulton St.                  |                                  |
|   New York, NY  10038            |   http://www.pencom.com/         |
+----------------------------------+----------------------------------+

Received on Thursday, 5 September 1996 12:26:09 UTC