Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [udig-devel] how do I create a P2P SearchView? 
Leon wrote:

Hello everybody,

I am writing a P2P application which should let one search for maps, layers
services etc. I am thinking of using uDig as a client. Essentially I should
have a view similar to the Search view with the input string for the query
above and the tree panel for the found results below.
That would be great! I started making a similar suggestion for google summer of code students here. If you want a wiki page to hack up design documents for discussion here it is: 
-

I already spent some
time trying to copy and modify
net.refractions.udig.catalog.ui.search.SearchView,

One possibility here is:
Location View is what you need hack up; what is needed is a search plugin (so you can add new kinds of searches). But we have a policy of not adding API until someone (ie you) ask for it on the list. Now I had a customer ask for this last month but I have since switched organizations and have lost touch. Let me drag up the API as I remember it and we can talk about it on the list here ... 
public interface Location {
public List<SimpleFeature> search( String text, Envelope bbox, IProgressMonitor monitor ) 
            throws IOException;
}

Not very complicated.

net.refractions.udig.catalog.ui.CatalogTreeViewer,
net.refractions.udig.catalog.internal.CatalogImpl but I am not getting too
far. It appears that SearchView is not suitable for my purposes as it does a
synchronous search on the on the IServices that are currently open in the
catalog while I need to do sent a query to my P2P network and asynchronously
add found services to the catalog.

Could anybody suggest how I should go about creating such a P2PSearchView? Unfortunately I could find very little architectural documents concerning uDig's catalog and you can get only so far by reading concurrent OO code.
That is fine; you need to create a *new* catalog; one that represents an external source of IService and IGeoResource information. As people find and select information from this catalog it will be added to the local one.
I have recast this idea of local and remote catalogs to be more clear in uDig 1.2 (ie udig trunk). Here it is 

ISearch <- IRepository <- ICatalog

Where:
- ISearch represents a remote service you can search for spatial information
- IRepository represents live connections to spatial information
-ICatalog - origional interface started off very pure but developed new features over time (hense the need to seperate out the above two).
If you would like to look at an implementation - please review the GoogleCatalog implementation - it is no longer included in the build since google turned off their SOAP access which was used to populate the database this thing connects to. 
 Also SearchView seems to be using a lot of classes in internal packages that I can't/shouldn't be using.
Once again; if you see something you want to use let us know and we will try and make it public for you. It is not worth making public api until someone needs it enough to be willing to talk about it (the best public API needs a couple of user stories to make it good anyways). 
Thanks,
Leon

Cheers,
Jody

Back to the top