Hi,
I'm trying to setup a new preview page and I'm getting
some nastiness trying to stick the two things, layers
and layers groups, in the same table.
Generally speaking it would be nice if Layer and LayerInfo
shared some superclass.
Failing that, it would be still nice if LayerGroupInfo
had at least:
- a workspace that contains it
- a isEnabled that just states whether all the layers in
the group are enabled or not (e.g., will the layer
group display or not^?)
Opinions? In the meantime I'm working around the above
limitations by creating a wrapping class only for the
map preview purposes
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Hi Andrea,
Andrea Aime wrote:
Hi,
I'm trying to setup a new preview page and I'm getting
some nastiness trying to stick the two things, layers
and layers groups, in the same table.
Generally speaking it would be nice if Layer and LayerInfo
shared some superclass.
I would prefer to favor composition over inheritance at least it _is_ a layer info and not just a group of layer infos? not the best timing for me to look deeper into it though, sorry
Failing that, it would be still nice if LayerGroupInfo
had at least:
- a workspace that contains it
sure
- a isEnabled that just states whether all the layers in
the group are enabled or not (e.g., will the layer
group display or not^?)
What about LayerGroupInfo.isEnabled() == true as long as at least one of its aggregated layerinfos is enabled? will this way allow for a layerGroupInfo to still be visualized while hiding the non enabled layers?
Opinions? In the meantime I'm working around the above
limitations by creating a wrapping class only for the
map preview purposes
I think that's cool if you have to deviate a little bit from the model for presentation purposes.
Cheers,
Gabriel
Cheers
Andrea
Gabriel Roldan ha scritto:
Hi Andrea,
Andrea Aime wrote:
Hi,
I'm trying to setup a new preview page and I'm getting
some nastiness trying to stick the two things, layers
and layers groups, in the same table.
Generally speaking it would be nice if Layer and LayerInfo
shared some superclass.
I would prefer to favor composition over inheritance at least it _is_ a layer info and not just a group of layer infos? not the best timing for me to look deeper into it though, sorry
Atm we have composition only. But it does not help if you're
trying to treat the two thing things as one (a displayable layer).
Failing that, it would be still nice if LayerGroupInfo
had at least:
- a workspace that contains it
sure
Actually I'm getting a little confused here. LayerInfo does not
have it either... I guess layers should be part of a Map instead,
but that is not there either.
Which basically means our WMS on trunk is broken,
does not support multiple containers anymore (as the one on 1.7.x),
will break if there are two layers attached to resources with
the same name in different workspaces. 
Oh boy...
- a isEnabled that just states whether all the layers in
the group are enabled or not (e.g., will the layer
group display or not^?)
What about LayerGroupInfo.isEnabled() == true as long as at least one of its aggregated layerinfos is enabled? will this way allow for a layerGroupInfo to still be visualized while hiding the non enabled layers?
Nope, it's guaranteed to blow on your face atm.
I also usually prefer fail fast approach instead of returning
something else, and letting the user figure out why some parts
of the map are missing.
At least the admin should be able to configure this behaviour
(fail fast vs best effort).
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
This was indeed something I bounced back and forth on when redesigning the interfaces. And in the end it did not seem to make sense to have LayerGroup be a "layer", as many of the properties do not apply. As far as I know this is just an issue when trying to iterate everything "renderable" correct?
As for the workspace and enabled flag, yes that makes sense. Although I think Map would be the more appropriate container since we are dealing with publishing, but of course we are at an annoying middleground where the entity does not yet exist. Besides having a name, a container (map or workspace), and an enabled/disabled flag is there any other common properties they would share?
Andrea Aime wrote:
Hi,
I'm trying to setup a new preview page and I'm getting
some nastiness trying to stick the two things, layers
and layers groups, in the same table.
Generally speaking it would be nice if Layer and LayerInfo
shared some superclass.
Failing that, it would be still nice if LayerGroupInfo
had at least:
- a workspace that contains it
- a isEnabled that just states whether all the layers in
the group are enabled or not (e.g., will the layer
group display or not^?)
Opinions? In the meantime I'm working around the above
limitations by creating a wrapping class only for the
map preview purposes
Cheers
Andrea
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Andrea Aime wrote:
Gabriel Roldan ha scritto:
Hi Andrea,
Andrea Aime wrote:
Hi,
I'm trying to setup a new preview page and I'm getting
some nastiness trying to stick the two things, layers
and layers groups, in the same table.
Generally speaking it would be nice if Layer and LayerInfo
shared some superclass.
I would prefer to favor composition over inheritance at least it _is_ a layer info and not just a group of layer infos? not the best timing for me to look deeper into it though, sorry
Atm we have composition only. But it does not help if you're
trying to treat the two thing things as one (a displayable layer).
Failing that, it would be still nice if LayerGroupInfo
had at least:
- a workspace that contains it
sure
Actually I'm getting a little confused here. LayerInfo does not
have it either... I guess layers should be part of a Map instead,
but that is not there either.
Which basically means our WMS on trunk is broken,
does not support multiple containers anymore (as the one on 1.7.x),
will break if there are two layers attached to resources with
the same name in different workspaces. Oh boy...
Yes, this is an issue. One we are sort of working around by having the catalog recognize layer names of the form <workspaceName>:<resourceName>. But I agree, not ideal. Again this middle ground of not having the "Map" container, but trying to design with it in mind is haunting us.
- a isEnabled that just states whether all the layers in
the group are enabled or not (e.g., will the layer
group display or not^?)
What about LayerGroupInfo.isEnabled() == true as long as at least one of its aggregated layerinfos is enabled? will this way allow for a layerGroupInfo to still be visualized while hiding the non enabled layers?
Nope, it's guaranteed to blow on your face atm.
I also usually prefer fail fast approach instead of returning
something else, and letting the user figure out why some parts
of the map are missing.
At least the admin should be able to configure this behaviour
(fail fast vs best effort).
Cheers
Andrea
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Justin Deoliveira ha scritto:
This was indeed something I bounced back and forth on when redesigning the interfaces. And in the end it did not seem to make sense to have LayerGroup be a "layer", as many of the properties do not apply. As far as I know this is just an issue when trying to iterate everything "renderable" correct?
Yep, so the issue presents itself when generating the wms capabilities
and the preview list (they are, in fact, strictly connected.
As for the workspace and enabled flag, yes that makes sense. Although I think Map would be the more appropriate container since we are dealing with publishing, but of course we are at an annoying middleground where the entity does not yet exist. Besides having a name, a container (map or workspace), and an enabled/disabled flag is there any other common properties they would share?
Nope, not at the moment.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.