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?
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.
Cheers,
Gabriel
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
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
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
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
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.
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
Gabriel Roldan ha scritto:
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.
Wow, nice, good job!
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.
Not sure I'll have time shortly but I'll try to have a look at the changes before next week
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.