Andrea Aime wrote: > 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. > Yeah, I think this will work with one caveat. We need to get the ID's set up properly. Currently id is always == name... we should change that. Once that is in place we can make the REsourceInfo name editable. > 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()). Yeah... that is probably a good idea until we have the true split. +1. > > Cheers > Andrea >
-- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------------ 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
