Justin Deoliveira ha scritto: ... >> Mind, alias has never been a collection. It was implemented >> as a way to rename a feature type, not to provide a second >> name for it. But the name it was give created (and is still >> creating) confusion. > Yeah... I think alias is not the best name for the function it provides, > and this is something i tried to fix when i revamped the model. If we do > not have any useful function for an actual "alias", that is a secondary > name for a layer, then i suggest we remove it to prevent further confusion.
Agreed. http://jira.codehaus.org/browse/GEOS-2774 >>> I agree that Layer.getName() is the best long term solution for a >>> published name. But as you point out this requires that we have >>> services go through Layers, not resources -> ie, the >>> resource/publishing split we oh so long for. Part of that is >>> introducing maps so that layer names can be qualified. So the map will >>> become the "namespace" for the layer name. >> It would be the namespace prefix that we use today. But not a real >> WFS namespace. So, will we associate a real namespace URI to maps >> as well? Or we take the native one coming from the resource? >> (assuming there is no community schema mapping) > I am not sure i follow. The original question is how do we make layer > names unique? My answer was that once layers are grouped by map, the > name of the map becomes the qualifier. Exactly how we look up stores > today, qualifying them with a workspace. Am i making any sense? > > In terms of "namespaces", I think a namespace should just refer to an > attribute of a Layer. Not a grouping mechanism. Workspaces and maps are > the grouping mechanisms. Sure a bunch of layers can have the same > namespace... but i don't think they should be "grouped" by that > namespace per se. Works for me. So for the moment we have to avoid confusing the users more than necessary. It seems to me the following solution could apply as long as we don't have a real resource/publishing split: - have the ResourceInfo name be editable (it's not atm) - have the LayerInfo name be non editable, and always equal to the resource info one. We'll make it editable again when a real resource/layer split will be worked on. The latter will keep the current wms/wfs/wcs relantionship where the same resource has the same name regardless of what service you use to access it (as opposed to start confusing the users as to why topp:states is available on wfs, but on wms you have to call it MyEditedLayerName only because the user changed the layer name by accident). I'm wondering how to tackle the second part thought. UI wise I can make that happen and it's easy, but what about REST config, or anyone fiddling directly in the xml files (I know, not supported, but people will do it anyways)? Wondering if implementation wise we should, just for the moment, wire the layer name directly onto its resource one (have LayerInfoImpl.getName() forward to getResource().getName()). Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
