Geoserver Ext Js Configuration UI and about REST API

[Björn Harrtell]

Hey Geoserver users and devs,

I've been doing some work on using the Geoserver configuration REST
API plugin with Ext Js as a frontend. The project is called gecui and
has its home at:

http://github.com/bjornharrtell/gecui

A recent snapshot of the GUI can be directly viewed here:

http://wiki.github.com/bjornharrtell/gecui

I did this mostly as an experiment and to have fun with the REST
configuration API, but who knows - if written in components the GUI
parts could be reused and using Ext Js makes for integration with
GeoExt to provide previews and whatnot - perhaps even direct editing
though WFS of the associated Geoserver layers - kind of an out of the
box web based GIS (oh no? :).

----

Anyhow, going forward with this project could benefit from some
adjustments/additions to the REST interface so here follows technical
ramblings for the dev-interested folks:

Collections are represented "strangely" in the Geoserver REST API. For
instance, a collection of featuretypes is { featureTypes: {
featureType: [] } }. IMHO it would be more sane to represent a
collection as an array directly like { featureTypes: [] }. This small
change would make it much easier to work the the REST API using Ext
Js. This is because a collection of things in JSON is usually
represented by the array literal notation directly (check out GeoJSON
spec for instance).

The Ext Js specific explanation is that Ext Js has definitions for
generic data structures (not really Ext Js specific in their essence).
A summary:

A nice example when data is bound to a grid and form simultaneously:
http://www.extjs.com/deploy/dev/examples/form/form-grid.html

The above example uses the idea of row-based collections with the
existing implementation for Json (there are existing bindings for XML
too) described here:
http://www.extjs.com/deploy/dev/docs/output/Ext.data.JsonReader.html

In addition to the row-based data spec, in Ext Js 3.0 CRUD operations
on row level data is supported by the JsonReader/JsonWriter but is
loosely specified (no documentation). However it's quite simple and
the typical usage can be viewed here:
http://www.extjs.com/deploy/dev/examples/restful/restful.html (Use
FireBug to see update packet data format, it's really simple).

A separate structure for hierachical used for the tree-control is
described here:
http://www.extjs.com/deploy/dev/docs/source/TreePanel.html#cls-Ext.tree.TreePanel

So aside from the collection issue - adding Ext Js style metadata to
collections and additionally exposing tree panel structure for things
that suit it (like workspaces->datastore->featuretype hierarchy..) and
perhaps even support for the row CRUD stuff for some collection
resources would be nice too ;)

Note though that I'll hopefully be able to get quite a bit further
even with the REST API unchanged.

Regards,

Björn Harrtell

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Geoserver-users mailing list
Geoserver-users@...
https://lists.sourceforge.net/lists/listinfo/geoserver-users

[tommy408]

If you have time can you integrate Modest Map with Geoserver?   I think Modest Map is the fastest map client so far, just not a lot of compatibility.  

http://modestmaps.com/

[cholmez]

That's awesome, great work.  It'd be great to get that stuff in to
GeoExt, or at least extensions for GeoExt at some point.  Though we
built the new GeoServer UI in wicket I'm definitely interested in having
ext based configuration - handle the most common types of configuration
through reusable javascript components.

You should submit your suggestions to jira, so we can track them.  Not
sure if they'll get implemented - one thing we need to start to consider
soon is versioning of the rest api.  Since it's still an extension I
suppose we can still change it.  But I think relatively soon we should
start to ship it with the core.  And at that point people will want to
be able to rely on it - to do an upgrade and have it work exactly the
same way.

I'd say once we get 2-3 client libraries working it'll be good enough to
get in core.  This ext.js is one, and that guy Patel was working on a
java one.  And someone else was working on a groovy one, though I don't
know if they were talking about contributing it.  If we got a python or
php one we'd be fairly well covered.

C

Björn Harrtell wrote:

> Hey Geoserver users and devs,
>
> I've been doing some work on using the Geoserver configuration REST
> API plugin with Ext Js as a frontend. The project is called gecui and
> has its home at:
>
> http://github.com/bjornharrtell/gecui
>
> A recent snapshot of the GUI can be directly viewed here:
>
> http://wiki.github.com/bjornharrtell/gecui
>
> I did this mostly as an experiment and to have fun with the REST
> configuration API, but who knows - if written in components the GUI
> parts could be reused and using Ext Js makes for integration with
> GeoExt to provide previews and whatnot - perhaps even direct editing
> though WFS of the associated Geoserver layers - kind of an out of the
> box web based GIS (oh no? :).
>
> ----
>
> Anyhow, going forward with this project could benefit from some
> adjustments/additions to the REST interface so here follows technical
> ramblings for the dev-interested folks:
>
> Collections are represented "strangely" in the Geoserver REST API. For
> instance, a collection of featuretypes is { featureTypes: {
> featureType: [] } }. IMHO it would be more sane to represent a
> collection as an array directly like { featureTypes: [] }. This small
> change would make it much easier to work the the REST API using Ext
> Js. This is because a collection of things in JSON is usually
> represented by the array literal notation directly (check out GeoJSON
> spec for instance).
>
> The Ext Js specific explanation is that Ext Js has definitions for
> generic data structures (not really Ext Js specific in their essence).
> A summary:
>
> A nice example when data is bound to a grid and form simultaneously:
> http://www.extjs.com/deploy/dev/examples/form/form-grid.html
>
> The above example uses the idea of row-based collections with the
> existing implementation for Json (there are existing bindings for XML
> too) described here:
> http://www.extjs.com/deploy/dev/docs/output/Ext.data.JsonReader.html
>
> In addition to the row-based data spec, in Ext Js 3.0 CRUD operations
> on row level data is supported by the JsonReader/JsonWriter but is
> loosely specified (no documentation). However it's quite simple and
> the typical usage can be viewed here:
> http://www.extjs.com/deploy/dev/examples/restful/restful.html (Use
> FireBug to see update packet data format, it's really simple).
>
> A separate structure for hierachical used for the tree-control is
> described here:
> http://www.extjs.com/deploy/dev/docs/source/TreePanel.html#cls-Ext.tree.TreePanel
>
> So aside from the collection issue - adding Ext Js style metadata to
> collections and additionally exposing tree panel structure for things
> that suit it (like workspaces->datastore->featuretype hierarchy..) and
> perhaps even support for the row CRUD stuff for some collection
> resources would be nice too ;)
>
> Note though that I'll hopefully be able to get quite a bit further
> even with the REST API unchanged.
>
> Regards,
>
> Björn Harrtell
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Geoserver-users mailing list
> Geoserver-users@...
> https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
Chris Holmes
OpenGeo - http://opengeo.org
Expert service straight from the developers.

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Geoserver-users mailing list
Geoserver-users@...
https://lists.sourceforge.net/lists/listinfo/geoserver-users

[cholmez]

I think it should work pretty easily, since GeoWebCache supports a few
different tile structures, as does modest maps.  Just would need some
testing to make sure it works right, maybe a small bit of code.  Would
be great if someone could get it working and then make a demo plugin.
GeoWebCache ships by default with GeoServer.

tommy408 wrote:
> If you have time can you integrate Modest Map with Geoserver?   I think
> Modest Map is the fastest map client so far, just not a lot of
> compatibility.  
>
> http://modestmaps.com/

--
Chris Holmes
OpenGeo - http://opengeo.org
Expert service straight from the developers.

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Geoserver-users mailing list
Geoserver-users@...
https://lists.sourceforge.net/lists/listinfo/geoserver-users

[Björn Harrtell]

Nice to hear :)

I've been doing some more work and have managed to work around most of
the issues with the current REST interface so I'm not as worked up
about it now :) Although I had to dig quite a bit deeper into Ext data
structure classes for forms and trees and customize accordingly. The
"collection issue" is worked around in the ResourceReader.js class. I
do still think using "native" JSON arrays for collections would be
more logical though so I have created a JIRA on that.

The tree is now loading async. One idea I'd like to demonstrate some
time would be to use the resource tree for several geoserver
instances. I'm thinking an organisation that has like 10+ instances of
geoservers and want to easily manage them in one place.

I've also added some experimental integration with GeoExt to preview
layers and intitial support for CRUD operations for all resources.
Next steps I guess would be to get the resource forms to a more
complete state and implement context menus to add/delete on the
supported resources (for now there is only an experimental delete on
featuretypes).

I do see one design issue with the REST API at the moment though.
Layers and styles live their own life in the REST API (with respect to
workspaces/namespaces) which seem especially problematic for layers,
causing their names to potentially not to be unique.. (correct me if
I'm wrong here?)

/Björn


2009/10/21 Chris Holmes <cholmes@...>:

> That's awesome, great work.  It'd be great to get that stuff in to GeoExt,
> or at least extensions for GeoExt at some point.  Though we built the new
> GeoServer UI in wicket I'm definitely interested in having ext based
> configuration - handle the most common types of configuration through
> reusable javascript components.
>
> You should submit your suggestions to jira, so we can track them.  Not sure
> if they'll get implemented - one thing we need to start to consider soon is
> versioning of the rest api.  Since it's still an extension I suppose we can
> still change it.  But I think relatively soon we should start to ship it
> with the core.  And at that point people will want to be able to rely on it
> - to do an upgrade and have it work exactly the same way.
>
> I'd say once we get 2-3 client libraries working it'll be good enough to get
> in core.  This ext.js is one, and that guy Patel was working on a java one.
>  And someone else was working on a groovy one, though I don't know if they
> were talking about contributing it.  If we got a python or php one we'd be
> fairly well covered.
>
> C
>
> Björn Harrtell wrote:
>>
>> Hey Geoserver users and devs,
>>
>> I've been doing some work on using the Geoserver configuration REST
>> API plugin with Ext Js as a frontend. The project is called gecui and
>> has its home at:
>>
>> http://github.com/bjornharrtell/gecui
>>
>> A recent snapshot of the GUI can be directly viewed here:
>>
>> http://wiki.github.com/bjornharrtell/gecui
>>
>> I did this mostly as an experiment and to have fun with the REST
>> configuration API, but who knows - if written in components the GUI
>> parts could be reused and using Ext Js makes for integration with
>> GeoExt to provide previews and whatnot - perhaps even direct editing
>> though WFS of the associated Geoserver layers - kind of an out of the
>> box web based GIS (oh no? :).
>>
>> ----
>>
>> Anyhow, going forward with this project could benefit from some
>> adjustments/additions to the REST interface so here follows technical
>> ramblings for the dev-interested folks:
>>
>> Collections are represented "strangely" in the Geoserver REST API. For
>> instance, a collection of featuretypes is { featureTypes: {
>> featureType: [] } }. IMHO it would be more sane to represent a
>> collection as an array directly like { featureTypes: [] }. This small
>> change would make it much easier to work the the REST API using Ext
>> Js. This is because a collection of things in JSON is usually
>> represented by the array literal notation directly (check out GeoJSON
>> spec for instance).
>>
>> The Ext Js specific explanation is that Ext Js has definitions for
>> generic data structures (not really Ext Js specific in their essence).
>> A summary:
>>
>> A nice example when data is bound to a grid and form simultaneously:
>> http://www.extjs.com/deploy/dev/examples/form/form-grid.html
>>
>> The above example uses the idea of row-based collections with the
>> existing implementation for Json (there are existing bindings for XML
>> too) described here:
>> http://www.extjs.com/deploy/dev/docs/output/Ext.data.JsonReader.html
>>
>> In addition to the row-based data spec, in Ext Js 3.0 CRUD operations
>> on row level data is supported by the JsonReader/JsonWriter but is
>> loosely specified (no documentation). However it's quite simple and
>> the typical usage can be viewed here:
>> http://www.extjs.com/deploy/dev/examples/restful/restful.html (Use
>> FireBug to see update packet data format, it's really simple).
>>
>> A separate structure for hierachical used for the tree-control is
>> described here:
>>
>> http://www.extjs.com/deploy/dev/docs/source/TreePanel.html#cls-Ext.tree.TreePanel
>>
>> So aside from the collection issue - adding Ext Js style metadata to
>> collections and additionally exposing tree panel structure for things
>> that suit it (like workspaces->datastore->featuretype hierarchy..) and
>> perhaps even support for the row CRUD stuff for some collection
>> resources would be nice too ;)
>>
>> Note though that I'll hopefully be able to get quite a bit further
>> even with the REST API unchanged.
>>
>> Regards,
>>
>> Björn Harrtell
>>
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and stay
>> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>> http://p.sf.net/sfu/devconference
>> _______________________________________________
>> Geoserver-users mailing list
>> Geoserver-users@...
>> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>
> --
> Chris Holmes
> OpenGeo - http://opengeo.org
> Expert service straight from the developers.
>

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Geoserver-users mailing list
Geoserver-users@...
https://lists.sourceforge.net/lists/listinfo/geoserver-users

[Justin Deoliveira-6]

Hi Björn,

Björn Harrtell wrote:

> Nice to hear :)
>
> I've been doing some more work and have managed to work around most of
> the issues with the current REST interface so I'm not as worked up
> about it now :) Although I had to dig quite a bit deeper into Ext data
> structure classes for forms and trees and customize accordingly. The
> "collection issue" is worked around in the ResourceReader.js class. I
> do still think using "native" JSON arrays for collections would be
> more logical though so I have created a JIRA on that.
>
> The tree is now loading async. One idea I'd like to demonstrate some
> time would be to use the resource tree for several geoserver
> instances. I'm thinking an organisation that has like 10+ instances of
> geoservers and want to easily manage them in one place.
>
> I've also added some experimental integration with GeoExt to preview
> layers and intitial support for CRUD operations for all resources.
> Next steps I guess would be to get the resource forms to a more
> complete state and implement context menus to add/delete on the
> supported resources (for now there is only an experimental delete on
> featuretypes).
>
> I do see one design issue with the REST API at the moment though.
> Layers and styles live their own life in the REST API (with respect to
> workspaces/namespaces) which seem especially problematic for layers,
> causing their names to potentially not to be unique.. (correct me if
> I'm wrong here?)

Yup, you are exactly right. This is a problem with api that stems from
the current state of layer in the configuration. This is planned to be
fixed when we have the "resource publishing" split. The upshot of which
is that the idea of a map will be the equivalent to the idea of a
workspace, but on the publishing side. This means that layers will be
qualified by maps the same way that resources are qualified by workspaces.

-Justin

>
> /Björn
>
>
> 2009/10/21 Chris Holmes <cholmes@...>:
>> That's awesome, great work.  It'd be great to get that stuff in to GeoExt,
>> or at least extensions for GeoExt at some point.  Though we built the new
>> GeoServer UI in wicket I'm definitely interested in having ext based
>> configuration - handle the most common types of configuration through
>> reusable javascript components.
>>
>> You should submit your suggestions to jira, so we can track them.  Not sure
>> if they'll get implemented - one thing we need to start to consider soon is
>> versioning of the rest api.  Since it's still an extension I suppose we can
>> still change it.  But I think relatively soon we should start to ship it
>> with the core.  And at that point people will want to be able to rely on it
>> - to do an upgrade and have it work exactly the same way.
>>
>> I'd say once we get 2-3 client libraries working it'll be good enough to get
>> in core.  This ext.js is one, and that guy Patel was working on a java one.
>>  And someone else was working on a groovy one, though I don't know if they
>> were talking about contributing it.  If we got a python or php one we'd be
>> fairly well covered.
>>
>> C
>>
>> Björn Harrtell wrote:
>>> Hey Geoserver users and devs,
>>>
>>> I've been doing some work on using the Geoserver configuration REST
>>> API plugin with Ext Js as a frontend. The project is called gecui and
>>> has its home at:
>>>
>>> http://github.com/bjornharrtell/gecui
>>>
>>> A recent snapshot of the GUI can be directly viewed here:
>>>
>>> http://wiki.github.com/bjornharrtell/gecui
>>>
>>> I did this mostly as an experiment and to have fun with the REST
>>> configuration API, but who knows - if written in components the GUI
>>> parts could be reused and using Ext Js makes for integration with
>>> GeoExt to provide previews and whatnot - perhaps even direct editing
>>> though WFS of the associated Geoserver layers - kind of an out of the
>>> box web based GIS (oh no? :).
>>>
>>> ----
>>>
>>> Anyhow, going forward with this project could benefit from some
>>> adjustments/additions to the REST interface so here follows technical
>>> ramblings for the dev-interested folks:
>>>
>>> Collections are represented "strangely" in the Geoserver REST API. For
>>> instance, a collection of featuretypes is { featureTypes: {
>>> featureType: [] } }. IMHO it would be more sane to represent a
>>> collection as an array directly like { featureTypes: [] }. This small
>>> change would make it much easier to work the the REST API using Ext
>>> Js. This is because a collection of things in JSON is usually
>>> represented by the array literal notation directly (check out GeoJSON
>>> spec for instance).
>>>
>>> The Ext Js specific explanation is that Ext Js has definitions for
>>> generic data structures (not really Ext Js specific in their essence).
>>> A summary:
>>>
>>> A nice example when data is bound to a grid and form simultaneously:
>>> http://www.extjs.com/deploy/dev/examples/form/form-grid.html
>>>
>>> The above example uses the idea of row-based collections with the
>>> existing implementation for Json (there are existing bindings for XML
>>> too) described here:
>>> http://www.extjs.com/deploy/dev/docs/output/Ext.data.JsonReader.html
>>>
>>> In addition to the row-based data spec, in Ext Js 3.0 CRUD operations
>>> on row level data is supported by the JsonReader/JsonWriter but is
>>> loosely specified (no documentation). However it's quite simple and
>>> the typical usage can be viewed here:
>>> http://www.extjs.com/deploy/dev/examples/restful/restful.html (Use
>>> FireBug to see update packet data format, it's really simple).
>>>
>>> A separate structure for hierachical used for the tree-control is
>>> described here:
>>>
>>> http://www.extjs.com/deploy/dev/docs/source/TreePanel.html#cls-Ext.tree.TreePanel
>>>
>>> So aside from the collection issue - adding Ext Js style metadata to
>>> collections and additionally exposing tree panel structure for things
>>> that suit it (like workspaces->datastore->featuretype hierarchy..) and
>>> perhaps even support for the row CRUD stuff for some collection
>>> resources would be nice too ;)
>>>
>>> Note though that I'll hopefully be able to get quite a bit further
>>> even with the REST API unchanged.
>>>
>>> Regards,
>>>
>>> Björn Harrtell
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>>> is the only developer event you need to attend this year. Jumpstart your
>>> developing skills, take BlackBerry mobile applications to market and stay
>>> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>>> http://p.sf.net/sfu/devconference
>>> _______________________________________________
>>> Geoserver-users mailing list
>>> Geoserver-users@...
>>> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>> --
>> Chris Holmes
>> OpenGeo - http://opengeo.org
>> Expert service straight from the developers.
>>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Geoserver-users mailing list
> Geoserver-users@...
> https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Geoserver-users mailing list
Geoserver-users@...
https://lists.sourceforge.net/lists/listinfo/geoserver-users