Anil Ramnanan wrote:
Ross Gardler wrote:
You tell me. It is certainly easier to use the HTTP in the Forrest
plugin environment. However, you are working in a Java environment so
it may be better to use the Java API. Perhaps if you outline your
design ideas it will help us decide.
Ross
That as my thinking as well when I decided to use the Java API.
Here is the basic idea:
A Repository View that has a form that show a list of documents
available in the repository. This is the interface where the user
selects the documents that they want to include in the locatiomap. You
should be bale to drag and drop from here to the locatiomap view.
A form? Why not a tree, seems more natural to me and you already have an
abstract class to handle tree views.
This Repository View will get it's information from a Document List
class. This class provides a listing of documents available from the
repository. This is not linked to a any particular repository but gets
its document list from classes that would query repositories specified
by the user such as the Daisy repository.
Tis sounds more like an interface. I'm not sure you can create *one*
class that would be able to retrieve documents form multiple
repositories. It would probably make more sense to define an interface
and then have specific repository plugins provide implmentations for
that interface.
Doing it this way you don't have one central class to be maintained by
all the different repository instances. Instead each repository
maintains its own implementation. If we are really lucky some of them
(like lenya) will maintain this class in their own code base (where it
should be really).
The Document List class can be
configured by a Preferences page which would allow you to select which
repository you are using and the settings for that particular repository
(username, password etc).
This preferences would then be provided by the repository plugins.
Then there are the repository specific classes for Daisy which would
query the daisy repository and return the list of documents to the
Documents List class. Here we use Daisy's Java API to query the repository.
And these also would be a part of the DaisyPlugin.
I think you are right, the Java API is probably best.
So does all this mean that we have something like:
package org.apache.forrest.view
/**
* A tree navigator that displays the contents of a repository
*/
public class RepositoryNavigator
---
package org.apache.forrest.repository
/**
* An interface describing the methods required to interface with
* and interact with an external repository.
*/
public class IRepositoryConnection
/**
* A content provider that presents the content of a repository
* to a graphical widget for display.
*/
public class RepositoryContentProvider implements
IStructuredContentProvider
/**
* A label provider that provides labels for the content of a
* repository for display in a treeView.
*/
public class RepositoryLabelProvider extends LabelProvider implements
ITreeLabelProvider
---
package org.daisy.forrest.repository;
/**
* An implementation of a connection to a Daisy Repository
*/
public class RepositoryConnection implements
IRepositoryConnection
---
The RepositoryConnection can do all the communicating with the
repository as you suggest. It would provide instances of the content and
label providers for the view.
---
Does this fit with what you were planning?
Ross
