hey, so the store extension point went quite well. Check out <http://jira.codehaus.org/browse/GEOS-3310> for a couple pictures of the arcsde coverage one running.
It replaces the single URL input field by separate input fields for the connection parameters. In addition, it allows to quickly fill out the connection params from any other existing arcsde store, either vector or raster, and to choose the raster table to work upon from a combobox instead of having to write it down (and know the table name before hand). Reviews welcome though. Cheers, Gabriel Gabriel Roldan wrote: > Hi, > > thanks for the response. > > So I agree the coverage/store multiplicity is a tough one. > I guess my best bet is to fall back to a custom edit page for ArcSDE > that at least allows to configure the connection parameters and choose > the raster from a combobox, but still requires one coverage per store. > > I can make it easier though by having a combobox allowing to select an > existing arcsde coverage store and then use the same connection > properties than the selected one for the new one. > > ComponentClass property on DataStorePanelInfo sounds good, but I wonder > whether we want it to be the whole edit page or a specific component to > fill out the form with. Reason being I would prefer to favor composition > over inheritance, so the *StoreNew/EditPage uses this component to fill > out the store's specific properties but is still in control of the > workflow... I should better be providing a patch though... > > Cheers, > Gabriel > > Justin Deoliveira wrote: >> 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
