Going through the "various datastore page improvements" issue, I ran myself into some confusion:
- why can't the store add/edit page change the workspace the store belongs to?
- Are workspaces and namespaces truly separated yet? Think of the DataStoreInfo's namespace parameter. I should set the datastore namspace parameter be selectable through a combobox, but, can it be different than the workspace now?
My understanding is that, even if workspaceInfo and NamespaceInfo are totally different beasts, when you create a Workspace a NamespaceInfo is created with the ws name as prefix, but they have different life cycles from there on, so I _should_ be able of selecting a workspace and a namespace for datastore as separate issues?
--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.
I believe your understanding is correct. Unfortunately we are at an annoying situation where the two are coupled.
Currently on the workspace edit page, you can set a namespace uri. This under the covers sets the implicit uri for the namespace kept in sync with the the workspace. The namespace prefix always equals the workspace name.
What we need to do is move namespace to be a property of resource, or more ideally layer. If you look at step "Port services to LayerInfo" in the resource publishing split proposal, you will see the following methods added to LayerInfo.
NamespaceInfo getNamespace()
void setNamespace(NamespaceInfo)
That said, there should be nothing stopping the changing of the workspace of a store.
-Justin
Gabriel Roldan wrote:
Going through the "various datastore page improvements" issue, I ran myself into some confusion:
- why can't the store add/edit page change the workspace the store belongs to?
- Are workspaces and namespaces truly separated yet? Think of the DataStoreInfo's namespace parameter. I should set the datastore namspace parameter be selectable through a combobox, but, can it be different than the workspace now?
My understanding is that, even if workspaceInfo and NamespaceInfo are totally different beasts, when you create a Workspace a NamespaceInfo is created with the ws name as prefix, but they have different life cycles from there on, so I _should_ be able of selecting a workspace and a namespace for datastore as separate issues?
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
cool, that's enough info as to keep going on with this specific issue.
Thanks,
Gabriel
Justin Deoliveira wrote:
I believe your understanding is correct. Unfortunately we are at an annoying situation where the two are coupled.
Currently on the workspace edit page, you can set a namespace uri. This under the covers sets the implicit uri for the namespace kept in sync with the the workspace. The namespace prefix always equals the workspace name.
What we need to do is move namespace to be a property of resource, or more ideally layer. If you look at step "Port services to LayerInfo" in the resource publishing split proposal, you will see the following methods added to LayerInfo.
NamespaceInfo getNamespace()
void setNamespace(NamespaceInfo)
That said, there should be nothing stopping the changing of the workspace of a store.
-Justin
Gabriel Roldan wrote:
Going through the "various datastore page improvements" issue, I ran myself into some confusion:
- why can't the store add/edit page change the workspace the store belongs to?
- Are workspaces and namespaces truly separated yet? Think of the DataStoreInfo's namespace parameter. I should set the datastore namspace parameter be selectable through a combobox, but, can it be different than the workspace now?
My understanding is that, even if workspaceInfo and NamespaceInfo are totally different beasts, when you create a Workspace a NamespaceInfo is created with the ws name as prefix, but they have different life cycles from there on, so I _should_ be able of selecting a workspace and a namespace for datastore as separate issues?
--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.