Justin Deoliveira ha scritto: > Hi Andrea, > > Yes, I agree that the situation now is not ideal. Currently ResourceInfo > has: > > getName() -> its published name (what we call alias today) > getNativeName() -> the physical name > getAlias() -> collection of "aliases"
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. > I believe we achieve aliasing now with getName() and getNativeName(). Oh, do we? This is new to me. But then again, I don't have good grips on how the catalog works right now. So the resource pool applies a retyping data store using getName()? > 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) 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
