Gabriel Roldan wrote: > Hi, > > long time ago we talked about the store edit pages to be extensible, and > the default ones being a fall back for stores that does not provide > their own configuration page. > Well, most of them doesn't really need a custom config page, but I'm > running into the need to do so for ArcSDE. > > Reason being that it is really weird for the ArcSDE raster configuration > to require a URL containing the user and password information. Moreover, > it would be good to being able of setting up the connection info once > and have all the available rasters in the databse to show up as resources. > > So this is a two-folded issue. By one side I'm wondering how an > extension point for store edit pages would be. I envision something > similar to CatalogIconFactory.getStoreIcon. That is, DataStorePanelInfo > is already being used as extension point for custom icons. We can extend > it to also serve as the extension point to get the store's edit form? > Does that sound like a good plan or someone with more wicket experience > recommends otherwise?
I don't see why not. From what I can see none of the bean instances of DataStoreInfoPanel define a componentClass... which means I guess they are only used for icons. So I think it makes sense to have the componentClass be the form or the page which is the customized ui. The componentClass may need to be narrowed to a specific abstract class... since you will need to get a map of connection parameters from the page? Be interested to hear what Andrea thinks, since he designed the class. > > The other side of the fence is related to overcoming the current > limitation of a CoverageStore serving one and only one Coverage. I know > this is due to the current geotools coverage API being designed for > single files and hence doesn't provide for relating more than one > coverage to a coverage store. The new API being worked out by Simone > will solve this. In the mean time, for the database holding lots of > rasters case, I would like to see how I could achieve that. That is, > configuring a single CoverageStore that relates to more than one > coverage. But I'm not getting anywhere, may be this is just not > possible, since it looks like ResourcePool and Catalog irreversibly ties > a CoverageStoreInfo to a single CoverageInfo? Anyway, any clue on if and > how we could circumvent that would be highly appreciated. > Yeah... this is going to be a hard assumption to break, and will take some work updating the various parts of geoserver that make that assumption. I would say we probably want to wait for the new coverage api to land before making any fast moves. But hopefully Simone can speak more to that point. > Cheers, > Gabriel > > > > > > > > > > > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Geoserver-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geoserver-devel -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
