[Geoserver-devel] Easing the life of users implementing ajax client apps with Geoserver

GeoServer GeoServer Developer
1

Hi,
I had this idea rolling in my mind for quite a bit: adding a javascript client that can talk back to geoserver with ajax calls is... humm...
too hard now.

First of all, there is the issue of putting the files somewhere they
can be served. So, you basically have to:
a) roll your own extra web app, for which you need a little java
    container webapps
b) unpack geoserver, and modify the webapp contents
c) use Apache or a separate static pages web server

a) and b) require some java webapps knowledge. Not too sure our
average user can do that. Besides this, b) is a bad idea, because
you mix your own code with Geoserver one, and you have to
redo the "mix" every time you upgrade Geoserver.

c) works if you have Apache or IIS knowledge, but then you may be
stuck with ajax calls. One thing that's not very well known, is
that ajax calls are sandboxed, you can call back only the server
that provided the javascript code. This rules out c), and makes
it impossible to use WFS-T, unless you are so good to know
how to proxy Geoserver with Apache, making the outside world
think you are serving everything from the same server.

The idea I have is really simple (thanks Chris and Justin for
the contributions on it): we add a data_dir/www folder in the
Geoserver data directory, and create a servlet that serves
it straight on http://myserver:8080/geoserver/www.
This directory can contain only static files, no jsp, no dinamic
stuff whatsoever (if you're in that business, it makes sense
to explore option a) or c) again), but it will allow everybody
to serve static files directly from their data dir.

On a long term vision, you could have all
your data in the data dir, and your custom application as well,
easily portable from one location to another, and no
fiddling when upgrading Geoserver.

Tecnically this should not be too hard, Justin already provided
us with a servlet that can serve straight from the data dir,
so it's a config and backport away (yeah, I would like to have
this in 1.5.2).

Well, how does this sound?
Cheers
Andrea

2

+1 from me Andrea. I like the name "www" too ;). Also, you may be
pleasantly surprised to know that the servlet that publishes straight up
web content has already been back ported to 1.5.x.

-Justin

Andrea Aime wrote:

Hi,
I had this idea rolling in my mind for quite a bit: adding a javascript
client that can talk back to geoserver with ajax calls is... humm...
too hard now.

First of all, there is the issue of putting the files somewhere they
can be served. So, you basically have to:
a) roll your own extra web app, for which you need a little java
    container webapps
b) unpack geoserver, and modify the webapp contents
c) use Apache or a separate static pages web server

a) and b) require some java webapps knowledge. Not too sure our
average user can do that. Besides this, b) is a bad idea, because
you mix your own code with Geoserver one, and you have to
redo the "mix" every time you upgrade Geoserver.

c) works if you have Apache or IIS knowledge, but then you may be
stuck with ajax calls. One thing that's not very well known, is
that ajax calls are sandboxed, you can call back only the server
that provided the javascript code. This rules out c), and makes
it impossible to use WFS-T, unless you are so good to know
how to proxy Geoserver with Apache, making the outside world
think you are serving everything from the same server.

The idea I have is really simple (thanks Chris and Justin for
the contributions on it): we add a data_dir/www folder in the
Geoserver data directory, and create a servlet that serves
it straight on http://myserver:8080/geoserver/www.
This directory can contain only static files, no jsp, no dinamic
stuff whatsoever (if you're in that business, it makes sense
to explore option a) or c) again), but it will allow everybody
to serve static files directly from their data dir.

On a long term vision, you could have all
your data in the data dir, and your custom application as well,
easily portable from one location to another, and no
fiddling when upgrading Geoserver.

Tecnically this should not be too hard, Justin already provided
us with a servlet that can serve straight from the data dir,
so it's a config and backport away (yeah, I would like to have
this in 1.5.2).

Well, how does this sound?
Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:4007,467c0f293501804284693!

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

3

+1 from me too, although I'd like to see it as part of a larger 'auto-client-generator' package that makes nice-looking, highly functional mapbuilder/openlayers/googlemaps/etc clients using a point-n-click gui.

We could call it 'GWD', or 'GeoServer World Domination'.

--saul

________________________________

From: geoserver-devel-bounces@lists.sourceforge.net on behalf of Justin Deoliveira
Sent: Fri 6/22/2007 2:26 PM
To: Andrea Aime
Cc: Geoserver-devel
Subject: Re: [Geoserver-devel] Easing the life of users implementing ajax client apps with Geoserver

+1 from me Andrea. I like the name "www" too ;). Also, you may be
pleasantly surprised to know that the servlet that publishes straight up
web content has already been back ported to 1.5.x.

-Justin

Andrea Aime wrote:

Hi,
I had this idea rolling in my mind for quite a bit: adding a javascript
client that can talk back to geoserver with ajax calls is... humm...
too hard now.

First of all, there is the issue of putting the files somewhere they
can be served. So, you basically have to:
a) roll your own extra web app, for which you need a little java
    container webapps
b) unpack geoserver, and modify the webapp contents
c) use Apache or a separate static pages web server

a) and b) require some java webapps knowledge. Not too sure our
average user can do that. Besides this, b) is a bad idea, because
you mix your own code with Geoserver one, and you have to
redo the "mix" every time you upgrade Geoserver.

c) works if you have Apache or IIS knowledge, but then you may be
stuck with ajax calls. One thing that's not very well known, is
that ajax calls are sandboxed, you can call back only the server
that provided the javascript code. This rules out c), and makes
it impossible to use WFS-T, unless you are so good to know
how to proxy Geoserver with Apache, making the outside world
think you are serving everything from the same server.

The idea I have is really simple (thanks Chris and Justin for
the contributions on it): we add a data_dir/www folder in the
Geoserver data directory, and create a servlet that serves
it straight on http://myserver:8080/geoserver/www.
This directory can contain only static files, no jsp, no dinamic
stuff whatsoever (if you're in that business, it makes sense
to explore option a) or c) again), but it will allow everybody
to serve static files directly from their data dir.

On a long term vision, you could have all
your data in the data dir, and your custom application as well,
easily portable from one location to another, and no
fiddling when upgrading Geoserver.

Tecnically this should not be too hard, Justin already provided
us with a servlet that can serve straight from the data dir,
so it's a config and backport away (yeah, I would like to have
this in 1.5.2).

Well, how does this sound?
Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:4007,467c0f293501804284693!

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org/>

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

4

Farber, Saul (EEA) ha scritto:

+1 from me too, although I'd like to see it as part of a larger
'auto-client-generator' package that makes nice-looking, highly
functional mapbuilder/openlayers/googlemaps/etc clients using a
point-n-click gui.

We could call it 'GWD', or 'GeoServer World Domination'.

Ah ha ha ha... I like this one :slight_smile:

Ok seriously, I want to have a generator too, what's keeping
me from implementing it is... Struts.
But then again, that would be a dynamic generator, much like
the current openlayers output format, just with a configuration
with more options, in a web page (or not? what was your idea of it?).
Once you like the result, you save and customize... and here
enters into the picture that www directory, which I'm envisioning
for static, hand made stuff.

Cheers
Andrea

5

Andrea,

Well, my extremely rough (as in stream-of-consciousnes) thoughts were something like this:

* GWD could be fairly independent from the GS core. It's actually a fairly generic client-creator, possibly with some geoserver-specific extensions to the clients it creates.

* Created clients would fit into three possible classes:
1) AJAX/html/JS only clients...are completely portable and only require a web server to run.
2) AJAX/html/JS + proxy clients...are very portable, but require something like the proxy.php/Proxy.java mapbuilder 'javascript proxy' on the hosting server so as to provide access to remote WFS/XML entities. By the way, how does Google's XML class in the mapping api handle this?
3) Full-on web-application based clients...are less portable, but can be delivered as a custom-generated .war file and could be deployed on any servlet container

* Client creation would be 'modular', in that there would be a way to create many types of clients. Client types (while broadly fitting into one of the three classes above) could be targeted in many ways:

* A 'general' client-generator module.
* A 'parcel viewer' client-generator module.
* A 'point editor' client-generator module.
* An 'news incident/emergency incident' client-generator module.
* etc.

* Generated clients (at least of the first two types) would be easily customizable with text editors and rudimentary javascript. In much the same way that the current openlayers outputformat gives people an immense head start in implementing an openlayers client based on geoserver, a client generated from one of the above client-generator modules would give people a 'running start' at their ideal client.

Ok, there's my pie in the sky client-generator ideas. I actually have the business case to work on a specific version of one of those client-generator modules in the next weeks...one that allows someone to create an openlayers map which is embedded into an environmental press release, and has basic redlining for marking up the area where the press release is focused.

What would you suggest for the client-generator module UI toolkit? Wicket? GWT? Something else?

--saul

________________________________

From: geoserver-devel-bounces@lists.sourceforge.net on behalf of Andrea Aime
Sent: Fri 6/22/2007 2:48 PM
To: Farber, Saul (EEA)
Cc: Geoserver-devel; Justin Deoliveira
Subject: Re: [Geoserver-devel] Easing the life of users implementing ajax client apps with Geoserver

Farber, Saul (EEA) ha scritto:

+1 from me too, although I'd like to see it as part of a larger
'auto-client-generator' package that makes nice-looking, highly
functional mapbuilder/openlayers/googlemaps/etc clients using a
point-n-click gui.

We could call it 'GWD', or 'GeoServer World Domination'.

Ah ha ha ha... I like this one :slight_smile:

Ok seriously, I want to have a generator too, what's keeping
me from implementing it is... Struts.
But then again, that would be a dynamic generator, much like
the current openlayers output format, just with a configuration
with more options, in a web page (or not? what was your idea of it?).
Once you like the result, you save and customize... and here
enters into the picture that www directory, which I'm envisioning
for static, hand made stuff.

Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

6

I have an ideal dream for client generation that's a bit different.

And we may actually get the opportunity to explore this a bit.

What I'd like to do is make it so OpenLayers can take an OWS Context file. All the client generators you speak of would basically just generate OWS Context files. If we need more advanced features we could perhaps expand OWS context.

But the point for me is that you could point OpenLayers directly at a Context config file and have your client, zoomed in where you want, with the styles you want and the data layers you want.

Then to go one beyond, openlayers would have widgets to add more data layers and to edit the SLD. So you could start with an interesting map, and then find some more WMS layers you'd like on it, zoom in on a new area, add a few georss markers, and save that. That would create a new Context doc, which you could then save and put on your own web page.

This then allows anyone to make a new map, and instead of just starting from a generator they can start from an existing map. It sorta brings the whole open source thing to the online map making context.

Chris

Farber, Saul (EEA) wrote:

Andrea,
Well, my extremely rough (as in stream-of-consciousnes) thoughts were something like this:
* GWD could be fairly independent from the GS core. It's actually a fairly generic client-creator, possibly with some geoserver-specific extensions to the clients it creates.
* Created clients would fit into three possible classes:
1) AJAX/html/JS only clients...are completely portable and only require a web server to run.
2) AJAX/html/JS + proxy clients...are very portable, but require something like the proxy.php/Proxy.java mapbuilder 'javascript proxy' on the hosting server so as to provide access to remote WFS/XML entities. By the way, how does Google's XML class in the mapping api handle this?
3) Full-on web-application based clients...are less portable, but can be delivered as a custom-generated .war file and could be deployed on any servlet container
* Client creation would be 'modular', in that there would be a way to create many types of clients. Client types (while broadly fitting into one of the three classes above) could be targeted in many ways:
* A 'general' client-generator module.
* A 'parcel viewer' client-generator module.
* A 'point editor' client-generator module.
* An 'news incident/emergency incident' client-generator module.
* etc.
* Generated clients (at least of the first two types) would be easily customizable with text editors and rudimentary javascript. In much the same way that the current openlayers outputformat gives people an immense head start in implementing an openlayers client based on geoserver, a client generated from one of the above client-generator modules would give people a 'running start' at their ideal client.
Ok, there's my pie in the sky client-generator ideas. I actually have the business case to work on a specific version of one of those client-generator modules in the next weeks...one that allows someone to create an openlayers map which is embedded into an environmental press release, and has basic redlining for marking up the area where the press release is focused.
What would you suggest for the client-generator module UI toolkit? Wicket? GWT? Something else?
--saul

________________________________

From: geoserver-devel-bounces@lists.sourceforge.net on behalf of Andrea Aime
Sent: Fri 6/22/2007 2:48 PM
To: Farber, Saul (EEA)
Cc: Geoserver-devel; Justin Deoliveira
Subject: Re: [Geoserver-devel] Easing the life of users implementing ajax client apps with Geoserver

Farber, Saul (EEA) ha scritto:

+1 from me too, although I'd like to see it as part of a larger
'auto-client-generator' package that makes nice-looking, highly
functional mapbuilder/openlayers/googlemaps/etc clients using a
point-n-click gui.

We could call it 'GWD', or 'GeoServer World Domination'.

Ah ha ha ha... I like this one :slight_smile:

Ok seriously, I want to have a generator too, what's keeping
me from implementing it is... Struts.
But then again, that would be a dynamic generator, much like
the current openlayers output format, just with a configuration
with more options, in a web page (or not? what was your idea of it?).
Once you like the result, you save and customize... and here
enters into the picture that www directory, which I'm envisioning
for static, hand made stuff.

Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:4005,467c38ea53195219720167!

--
Chris Holmes
The Open Planning Project
http://topp.openplans.org

7

Farber, Saul (EEA) ha scritto:

Andrea,

Well, my extremely rough (as in stream-of-consciousnes) thoughts were
something like this:

* GWD could be fairly independent from the GS core. It's actually a
fairly generic client-creator, possibly with some geoserver-specific
extensions to the clients it creates.

That would be ok

* Created clients would fit into three possible classes: 1)
AJAX/html/JS only clients...are completely portable and only require
a web server to run. 2) AJAX/html/JS + proxy clients...are very
portable, but require something like the proxy.php/Proxy.java
mapbuilder 'javascript proxy' on the hosting server so as to provide
access to remote WFS/XML entities. By the way, how does Google's XML
class in the mapping api handle this? 3) Full-on web-application
based clients...are less portable, but can be delivered as a
custom-generated .war file and could be deployed on any servlet
container

* Client creation would be 'modular', in that there would be a way to
create many types of clients. Client types (while broadly fitting
into one of the three classes above) could be targeted in many ways:

* A 'general' client-generator module. * A 'parcel viewer'
client-generator module. * A 'point editor' client-generator module. * An 'news incident/emergency incident' client-generator module. *
etc.

Hey, I'm loosing you :slight_smile: Ok, I think we could start doing a generic
generator, and keep some extension points so that people can
create their own version, targeted at a specific use case.

* Generated clients (at least of the first two types) would be easily
customizable with text editors and rudimentary javascript. In much
the same way that the current openlayers outputformat gives people an
immense head start in implementing an openlayers client based on
geoserver, a client generated from one of the above client-generator
modules would give people a 'running start' at their ideal client.

Yep, that's the idea.

What would you suggest for the client-generator module UI toolkit?
Wicket? GWT? Something else?

Heh, I would do it in Wicket straight away, since it allows to build
complex UI without getting crazy, and has some ajax capabilities
that you get almost for free. GWT could be good, I would have chosen
it to redo the Geosever UI if it was possible to build modular
UI with it (that is, runtime composable, out of the classpath modular,
not just OO modular).

Cheers
Andrea

8

Chris Holmes ha scritto:

I have an ideal dream for client generation that's a bit different.

And we may actually get the opportunity to explore this a bit.

What I'd like to do is make it so OpenLayers can take an OWS Context file. All the client generators you speak of would basically just generate OWS Context files. If we need more advanced features we could perhaps expand OWS context.

But the point for me is that you could point OpenLayers directly at a Context config file and have your client, zoomed in where you want, with the styles you want and the data layers you want.

Then to go one beyond, openlayers would have widgets to add more data layers and to edit the SLD. So you could start with an interesting map, and then find some more WMS layers you'd like on it, zoom in on a new area, add a few georss markers, and save that. That would create a new Context doc, which you could then save and put on your own web page.

This then allows anyone to make a new map, and instead of just starting from a generator they can start from an existing map. It sorta brings the whole open source thing to the online map making context.

Yeah, that would be good, it requires someone to hack into the OL core
so that OL can handle that out of the box (javascript wizards, anyone?).

Yet, in the mid term I would like to be able and have a full client
generated that does what pmapper does (pmapper being a popular choice
to do mapserver frontends):
http://www.pmapper.net/screenshots.shtml
The MapGuide open source gallery has very very nice frontends too:
http://mapguide.osgeo.org/livegallery.html

And if you think I'm asking for too much.... think again :slight_smile:
If the long term idea is to be a turnkey solution for web GIS, that's
where we need to go (and do some WPS too), it won't happen
overnight, but that's where I'd like to see Geoserver go.

Cheers
Andrea

9

Andrea Aime wrote:

Chris Holmes ha scritto:

I have an ideal dream for client generation that's a bit different.

And we may actually get the opportunity to explore this a bit.

What I'd like to do is make it so OpenLayers can take an OWS Context file. All the client generators you speak of would basically just generate OWS Context files. If we need more advanced features we could perhaps expand OWS context.

But the point for me is that you could point OpenLayers directly at a Context config file and have your client, zoomed in where you want, with the styles you want and the data layers you want.

Then to go one beyond, openlayers would have widgets to add more data layers and to edit the SLD. So you could start with an interesting map, and then find some more WMS layers you'd like on it, zoom in on a new area, add a few georss markers, and save that. That would create a new Context doc, which you could then save and put on your own web page.

This then allows anyone to make a new map, and instead of just starting from a generator they can start from an existing map. It sorta brings the whole open source thing to the online map making context.

Yeah, that would be good, it requires someone to hack into the OL core
so that OL can handle that out of the box (javascript wizards, anyone?).

Yet, in the mid term I would like to be able and have a full client
generated that does what pmapper does (pmapper being a popular choice
to do mapserver frontends):
http://www.pmapper.net/screenshots.shtml
The MapGuide open source gallery has very very nice frontends too:
http://mapguide.osgeo.org/livegallery.html

And if you think I'm asking for too much.... think again :slight_smile:
If the long term idea is to be a turnkey solution for web GIS, that's
where we need to go (and do some WPS too), it won't happen
overnight, but that's where I'd like to see Geoserver go.

Oh, I definitely agree. I do like doing things a bit differently and seeing where that takes us instead of trying to target the exact same functionality. But I think we can do both, because the routes that are a bit different can make it easy to evolve to meeting the same needs. I don't necessarily need javascript wizards, I'd just like whatever framework we use to generate Context docs that OL will read, instead of us generating a bunch of javascript. Note that it's looking very likely that there will be funding to get OL to do this type of thing.

Chris

Cheers
Andrea

!DSPAM:4005,467cdaff134181431913854!

--
Chris Holmes
The Open Planning Project
http://topp.openplans.org