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.

------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image 
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Reply via email to