Some thoughts:
I would be for a common interface for Layer and LayerGroup... but not sure
what a good name for it would be... I would also be for just using
CatalogInfo if it suffices for this use case.
If LayerGroupInfo#layers is going to become a derived property that
recursively returns all the leafs of the tree I would like to see it
deprecated and renamed to "layers()" to keep with derived property naming
conventions. I like either getItems() or getContents() for the property that
returns only the direct children of the layer group.
You might be able to save yourself some headaches with the REST api by
allowing one to POST to an existing layer group the name of a layer / or
another layer group, rather than forcing the client to encode the contents
in the metadata map.
Anyways... a fun problem, there will definitely be some tricky bits in there
:)
-Justin
The config
On Fri, Oct 7, 2011 at 11:04 AM, Gabriel Roldan <grol...@opengeo.org> wrote:
> Good stuff.
>
> It looks to me like LayerInfo and LayerGroupInfo could share some
> stuff though. Both are means of defining a WMS layer, but
> LayerGroupInfo is usually left aside when it comes to configuration
> properties.
> For instance, looks like they can share the following properties:
> enabled, legend, path, advertised, queryable, and AuthorityURL and
> Identifier once GEOS-4491 gets home. So I wouldn't mind a common
> superinterface?
>
> > List<CatalogInfo> getItems()
> >
> > Would this be ok?
> > Another thing is that the solution would be needed for the 2.1.x
> > series, so we'd need the
> > generic list of items to be stored among the metadata (fun eh?).
> I'm facing a similar problem with the backwards compatibility patch
> for GEOS-4491, as would need both LayerInfo and LayerGroupInfo to hold
> more than one AuthorityURL, and even funnier cause AuthorityURL is not
> a single string but a compound object.
>
> > Given that anything in the catalog as a globally unique di the
> > metadata could contain
> > a flat list of UUIDs, and the code parsing it would try each id for
> > both layer and layer group.
> >
> > Of course also the GUI would have to be updated. To keep things simple
> > we could have
> > a "add layer" and a "add group" button.
> > And finally the cascaded deletion code would have to care for groups in
> groups.
> >
> > Have I considered everything? Hmm... RESTConfig changes are going to
> > be real fun too...
> Keep in touch cause I think I'll also have to update the GWC catalog
> listener in order to resolve both contained layer and layergroups when
> truncated based on a config change.
>
> >
> > Opinions?
>
> Sounds good to me. I'd like to hear your opinions about the common
> superinterface for LayerInfo and LayerGroup though, perhaps only on
> trunk?
>
> Cheers,
> Gabriel.
> >
> > Cheers
> > Andrea
> >
> > --
> > -------------------------------------------------------
> > Ing. Andrea Aime
> > GeoSolutions S.A.S.
> > Tech lead
> >
> > Via Poggio alle Viti 1187
> > 55054 Massarosa (LU)
> > Italy
> >
> > phone: +39 0584 962313
> > fax: +39 0584 962313
> >
> > http://www.geo-solutions.it
> > http://geo-solutions.blogspot.com/
> > http://www.youtube.com/user/GeoSolutionsIT
> > http://www.linkedin.com/in/andreaaime
> > http://twitter.com/geowolf
> >
> > -------------------------------------------------------
> >
> >
> ------------------------------------------------------------------------------
> > All of the data generated in your IT infrastructure is seriously
> valuable.
> > Why? It contains a definitive record of application performance, security
> > threats, fraudulent activity, and more. Splunk takes this data and makes
> > sense of it. IT sense. And common sense.
> > http://p.sf.net/sfu/splunk-d2dcopy2
> > _______________________________________________
> > Geoserver-devel mailing list
> > Geoserver-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/geoserver-devel
> >
>
>
>
> --
> Gabriel Roldan
> OpenGeo - http://opengeo.org
> Expert service straight from the developers.
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2dcopy2
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
