[Geoserver-devel] MemoryModel_GeoserverConfig.pdf

GeoServer GeoServer Developer
1

Hey everyone good news!

We have an draft proposal for web based user interface configuration.

Please, if your holiday schedule allows, have a look over this document. We will be keeping a fairly aggressive schedule on this one (we hope to have the first prototype ready Jan 9th). So your timely feedback is greatly appriciated.

I will be away on holidays next week. Please send comments directly to the geoserver-devel list, my associates David Zwiers and Richard Gould will be happy to receive feedback, and incorporate list discussion into this design.

For the pdf impaired:
- breaking the configuration classes into a "Model" and "Application" components
- Struts based interaction with the "Model"
- "Model" load from XML
- "Model" save to XML
- "GeoServer" configuration from the model

For detailed user interface design, sample screens and all the good stuff please consult the attached pdf.

Jody Garnett

(attachments)

MemoryModel_GeoserverConfig.pdf (429 KB)

2

First of all, I like it. I have just a few comments about it:

CatalogConfig/DataStores:
- it would be great to have the connection parameters in a more table like display (two columns, parameter name/value pairs)

CatalogConfig/Features:
- I don't like the attributes section. It seems to be error prone to type the xml schema attributes there. Hopefully the attributes will be generated automatically soon.

I will love this. Thanks!

Simon

Hey everyone good news!

We have an draft proposal for web based user interface configuration.

Please, if your holiday schedule allows, have a look over this document. We will be keeping a fairly aggressive schedule on this one (we hope to have the first prototype ready Jan 9th). So your timely feedback is greatly appriciated.

I will be away on holidays next week. Please send comments directly to the geoserver-devel list, my associates David Zwiers and Richard Gould will be happy to receive feedback, and incorporate list discussion into this design.

For the pdf impaired:
- breaking the configuration classes into a "Model" and "Application" components
- Struts based interaction with the "Model"
- "Model" load from XML
- "Model" save to XML
- "GeoServer" configuration from the model

For detailed user interface design, sample screens and all the good stuff please consult the attached pdf.

Jody Garnett

<MemoryModel_GeoserverConfig.pdf>

3

Quoting Simon Raess <cocoa@anonymised.com>:
Thanks for the feedback Simon!

First of all, I like it. I have just a few comments about it:

CatalogConfig/DataStores:
- it would be great to have the connection parameters in a more table
like display (two columns, parameter name/value pairs)

You are totally right - I must of missed this in my review before we sent it out.

Just to carify we should do something similar to the attributes section.
Depending on the kind of parameter we will need to different widgets (or
possibly several widgets) to allow input. The easiest example to think of is
the password input required for most database access. We should use the html
password field.

The screen should look like:
Datastore ID: bizkaia.sde (text field, should not be enabled)
     Enabled: x
             (check box control)
   Namespace: cdf
Description: a whole bunch of text
             (this really needs to be a text area for _long_ descriptions)
      server: localhost
        port: 5151
    instance: sde ( I am not sure what instance means?!)
        user: sde
    password: **** ( Use the html password control)

dbtype also needs to be removed (we already know it is an arcsde datastore when
the user added the datastore)
I don't think Datastore ID should be enabled, we probably need to provide an
explicit DataStore "rename" action as we will need to a update all the
FeatureType definitions.

CatalogConfig/Features:
- I don't like the attributes section. It seems to be error prone to
type the xml schema attributes there. Hopefully the attributes will be
generated automatically soon.

I am actually counting on generating the initial list, the problem is that the
XMLSchema allows more powerful modeling then the DataStore/FeatureType schema
information provided by Geotools (or Databases). At the very least we will need
to use Text Areas to allow people to type more information in.

What would be really nice would be to look into the XMLSchema specificaiton and
come up with a series of controls to use once the type has been generated from
the DataStore/FeatureType information.

To change the example from the pdf:

      Name: bc_roads_Type
           (not sure what this means - a XMLSchema reference?)
  the_geom: gml:MultiLineString (type information - from select control?)
            nillable: X minOccurance=1 maxOccurance=2
            (series of controls applicable to MultiLineString)
    Length: xs:int (type information - from select control?)
            nillable: X minOccurance=1 maxOccurance=2 maxDigits=
            (series of controls applicable to xs:int)
BTRN_BC_ID: xs:int (type information - from select control?)
            nillable: X minOccurance=1 maxOccurance=2 maxDigits=2
            (series of controls applicable to xs:int)

I am afraid I also don't know a whole lot about styles, I am pretty focused on
the WFS side of things. I am hoping someone who understands WMS can work what
we need for Style information.

I will love this. Thanks!

I am looking forward to it as well, thanks for the feedback Simon.

Jody

4

> CatalogConfig/Features:
> - I don't like the attributes section. It seems to be error prone to
> type the xml schema attributes there. Hopefully the attributes will be
> generated automatically soon.

I am actually counting on generating the initial list, the problem is that the
XMLSchema allows more powerful modeling then the DataStore/FeatureType schema
information provided by Geotools (or Databases). At the very least we will need
to use Text Areas to allow people to type more information in.

What would be really nice would be to look into the XMLSchema specificaiton and
come up with a series of controls to use once the type has been generated from
the DataStore/FeatureType information.

One thing that could be worth considering (though I'm not sure how much
work it would be) is to provide a big chunk of functionality of XMLSchema,
and start out with having the validation code provide the checks,
eventually moving to geotools validation as their Feature model grows to
match the full capabilities of XMLSchema.

I am afraid I also don't know a whole lot about styles, I am pretty focused on
the WFS side of things. I am hoping someone who understands WMS can work what
we need for Style information.

I know the basics, but I think this would be a nice jira task, that
someone with wms and style knowledge could probably handle as a nice
contribution to geoserver. It would be really cool if we had some sort of
gui style builder, perhaps an interfact to Andrea's style builder code.
This is a non-trivial task, but would be nice, to be able to give users
the various style controls, and show them what their map would look like.
The geotools XMLEncoder could then be used to persist the styles.

I'll create the JIRA task, and people with firm idea on a gui for styles
can comment there.

Chris

5

I 'm in proccess of develope an Web admin service for Geoserver, but i don't
know how to make dinamic load the configuration i read the Memory model but
I don't know how to make this.

Bladimir Moreno