Justin Deoliveira ha scritto: > 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. Designed is a big word for such a small bean. But yeah, it was meant to be the place where you provide enough information to instantiate a custom panel. My first thought was actually to make the bean a factory for the panel, but since the custom is to make xxxInfo pure data holders we could have the Info carry the class name of a panel or a page, and have the it extend a base class with a constructor that receives the params. >> 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. I agree it will be messy and it's better wait to make a coverage api switch instead, so that at least we face issues just once. Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ 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
