[Geoserver-devel] GeoServer layer configuration GUI: dealing with Format's ReadParameters. Ask for feedbacks

GeoServer GeoServer Developer
1

Hi list,
I would like to ask you for some feedbacks on this topic:
In the last months the imageMosaic is growing and we are adding more readParameters when improving it in order to offer more capabilities (footprint management, filtering, support for time and elevation requests, interpolation type, … ).
When adding a GeneralParameterDescriptor to the readParameters in the setInfo method of the Format class, usually it is automatically exposed in the GeoServer GUI when configuring the layer (If my memory serves me right, there is a loop in the code which looks for parameters from the Format class and exposes them) and then it is serialized to XML.
However, there are some parameters we would like to not expose in the GUI (while some others may require a special management… but this last topic can be discussed later).
In such a context, which approach do you suggest to deal with this scenario, avoiding hard-coding on geoserver?
Should I, as an instance, “play” with wickets and setup custom editors to manage “special” parameters (which aren’t simpler String, doubles, enum…) as well as leverage on some null-editor when I don’t need to expose a parameter? (How?)

Feedbacks are very welcome.

Daniele

–

Ing. Daniele Romagnoli
Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313
mob: +39 328 0559267

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/

2

On Mon, Nov 15, 2010 at 5:06 PM, Daniele Romagnoli
<daniele.romagnoli@anonymised.com> wrote:

Hi list,
I would like to ask you for some feedbacks on this topic:
In the last months the imageMosaic is growing and we are adding more
readParameters when improving it in order to offer more capabilities
(footprint management, filtering, support for time and elevation requests,
interpolation type, ... ).
When adding a GeneralParameterDescriptor to the readParameters in the
setInfo method of the Format class, usually it is automatically exposed in
the GeoServer GUI when configuring the layer (If my memory serves me right,
there is a loop in the code which looks for parameters from the Format class
and exposes them) and then it is serialized to XML.
However, there are some parameters we would like to not expose in the GUI
(while some others may require a special management... but this last topic
can be discussed later).
In such a context, which approach do you suggest to deal with this scenario,
avoiding hard-coding on geoserver?
Should I, as an instance, "play" with wickets and setup custom editors to
manage "special" parameters (which aren't simpler String, doubles, enum...)
as well as leverage on some null-editor when I don't need to expose a
parameter? (How?)

Se here we have two problems:
- keeping the params in the programming interface without exposing
them in the GUI
- having a custom editor for some params that happen to be more than
just strings

I think that having a base abstract class for these parameter editors
and looking for
specific implementations in the app context using GeoserverExtensions could
be the way to go.
And yeah, one specific extension could be the "NullParameterEditor",
if a parameter
is associated to it then we just hide it from the GUI.

This parameter editor base class can probably have a
boolean accept(GeneralParameterDescriptor)
that can be then implemented by subclasses to decide which editor gets to deal
with that specific parameter?

Cheers
Andrea

-----------------------------------------------------
Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-----------------------------------------------------

3

Hi again,
I have a side question; see below.

On Mon, Nov 15, 2010 at 5:22 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Mon, Nov 15, 2010 at 5:06 PM, Daniele Romagnoli
<daniele.romagnoli@anonymised.com68…> wrote:

Hi list,
I would like to ask you for some feedbacks on this topic:
In the last months the imageMosaic is growing and we are adding more
readParameters when improving it in order to offer more capabilities
(footprint management, filtering, support for time and elevation requests,
interpolation type, … ).
When adding a GeneralParameterDescriptor to the readParameters in the
setInfo method of the Format class, usually it is automatically exposed in
the GeoServer GUI when configuring the layer (If my memory serves me right,
there is a loop in the code which looks for parameters from the Format class
and exposes them) and then it is serialized to XML.
However, there are some parameters we would like to not expose in the GUI
(while some others may require a special management… but this last topic
can be discussed later).
In such a context, which approach do you suggest to deal with this scenario,
avoiding hard-coding on geoserver?
Should I, as an instance, “play” with wickets and setup custom editors to
manage “special” parameters (which aren’t simpler String, doubles, enum…)
as well as leverage on some null-editor when I don’t need to expose a
parameter? (How?)

Se here we have two problems:

  • keeping the params in the programming interface without exposing
    them in the GUI

Do you know if, actually, setting the “required” parameter to false when constructing a new DefaultParameterDescriptor will be taken into account to be excluded by the parameter list exposed in the GUI?

Daniele

  • having a custom editor for some params that happen to be more than
    just strings

I think that having a base abstract class for these parameter editors
and looking for
specific implementations in the app context using GeoserverExtensions could
be the way to go.
And yeah, one specific extension could be the “NullParameterEditor”,
if a parameter
is associated to it then we just hide it from the GUI.

This parameter editor base class can probably have a
boolean accept(GeneralParameterDescriptor)
that can be then implemented by subclasses to decide which editor gets to deal
with that specific parameter?

Cheers
Andrea

Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/

http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

–

Ing. Daniele Romagnoli
Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313
mob: +39 328 0559267

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/

4

On Mon, Nov 15, 2010 at 5:29 PM, Daniele Romagnoli
<daniele.romagnoli@anonymised.com> wrote:

Do you know if, actually, setting the "required" parameter to false when
constructing a new DefaultParameterDescriptor will be taken into account to
be excluded by the parameter list exposed in the GUI?

I don't know, but if it does it would see like a bug to me. "Not
required" does not mean
"hidden", optional params are shown in the store GUI for example

Cheers
Andrea

-----------------------------------------------------
Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-----------------------------------------------------