[Geoserver-users] Web UI modularized !!!

GeoServer GeoServer User
1

Hi guys,

after several analysis and evaluations, finally I have created an example Web UI for GeoServer, based on wicket, which is capable to retrieve resources directly from the classpath, in order to let each module to have his own Web UI inside the JAR.
With this improvement we can plug-in/out modules along with theyr interfaces into GeoServer.

The module and the template, with some examples, is alredy available for your evaluation in the 1.4.x WCS branch.
I will wirte a detailed report describing all the evaluations and analysis made to reach this solution (as soon as possible).

Cheers,
Alessio.

–

Eng. Alessio Fabiani
Vice President/CTO GeoSolutions

http://www.geo-solutions.it

2

Rejoice!! Great work Alessio. I am excited to check out your work.

What is the state of the struts app on your branch. I know you did some
work figuring out how to do similar modularization with struts. The
reason I ask is because it would be nice to have the modularity with the
current app without switching to a new technology and rewriting it.

While on the topic, I spoke briefly with Simone about this and it would
nice to hear your thoughts about merging trunk and wcs branch up soon.
Simone brought up the point that it would be easiest to make the wcs
branch the new trunk, as it is has been bringing changes across from
trunk and has been much more active. Similar what we did with the 1.4.x
branch.

I know you guys are busy at the moment, as am I. So I intend to do up a
GSIP for this issue, and perhaps target its implementation for after
FOSS. Any thoughts?

-Justin

Alessio Fabiani wrote:

Hi guys,

after several analysis and evaluations, finally I have created an
example Web UI for GeoServer, based on wicket, which is capable to
retrieve resources directly from the classpath, in order to let each
module to have his own Web UI inside the JAR.
With this improvement we can plug-in/out modules along with theyr
interfaces into GeoServer.

The module and the template, with some examples, is alredy available for
your evaluation in the 1.4.x WCS branch.
I will wirte a detailed report describing all the evaluations and
analysis made to reach this solution (as soon as possible).

Cheers,
             Alessio.

--
-------------------------------------------------------
Eng. Alessio Fabiani
Vice President/CTO GeoSolutions

http://www.geo-solutions.it

---------------------------------------------------------
!DSPAM:1004,44e98787201111429667743!

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

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

!DSPAM:1004,44e98787201111429667743!

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

_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:1004,44e98787201111429667743!

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

3

On 8/21/06, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Rejoice!! Great work Alessio. I am excited to check out your work.

What is the state of the struts app on your branch. I know you did some
work figuring out how to do similar modularization with struts. The
reason I ask is because it would be nice to have the modularity with the
current app without switching to a new technology and rewriting it.

I have spent a lot of time trying to maintain the current architecture for the Web UI.
Very briefly my conclusion are the following:
1 - it’s quite easy to split struts-configs and tiles-defs descriptors (in the WCS branch there is a working example of this concept)
2 - it’s almost impossible to retrieve the JSP pages from the classpath unless we
2.a) rewrite from scratch the include method of the RequestContext
or
2.b) override some classes of the Struts framework in order to allow them to retrieve streams like XML,HTML,XHTML,… from the classpath and use them as template to build the JSP page

Both the above solutions require too much work given the fact that a lot of cool frameworks are already implemented like strutxx, wicket, JSF and so on… so the conclusions are that in any case we have to change deeply the architecture of the actual Web UI, and for this reason the better solution, on my opinion, is to start from scratch using the more clever and powerful architecture we can find … and I think that the Andrea proposal, i.e. wicket, is the one!

While on the topic, I spoke briefly with Simone about this and it would
nice to hear your thoughts about merging trunk and wcs branch up soon.
Simone brought up the point that it would be easiest to make the wcs
branch the new trunk, as it is has been bringing changes across from
trunk and has been much more active. Similar what we did with the 1.4.x
branch.

I know you guys are busy at the moment, as am I. So I intend to do up a
GSIP for this issue, and perhaps target its implementation for after
FOSS. Any thoughts?

Yes, I think that this is the fastest and easiest solution. The WCS branch IS trunk plus several improvements. But even an svn merge should not really be a problem.

-Justin

Alessio Fabiani wrote:

Hi guys,

after several analysis and evaluations, finally I have created an
example Web UI for GeoServer, based on wicket, which is capable to
retrieve resources directly from the classpath, in order to let each
module to have his own Web UI inside the JAR.
With this improvement we can plug-in/out modules along with theyr
interfaces into GeoServer.

The module and the template, with some examples, is alredy available for
your evaluation in the 1.4.x WCS branch.
I will wirte a detailed report describing all the evaluations and
analysis made to reach this solution (as soon as possible).

Cheers,
Alessio.

–

Eng. Alessio Fabiani
Vice President/CTO GeoSolutions

http://www.geo-solutions.it <http://www.geo-solutions.it>

!DSPAM:1004,44e98787201111429667743!

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

!DSPAM:1004,44e98787201111429667743!

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:1004,44e98787201111429667743!

–
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

–

Eng. Alessio Fabiani
Vice President/CTO GeoSolutions

http://www.geo-solutions.it

4

I would like to have a steady long term solution to these issues ... so let me try an informal "grand plan slam" so the ideas are out in the open.

Basically we are moving up a list of maturity form "modules" to "plugin", this was is expected by me - but not quite so soon :slight_smile: I set up a "scale" that I tried to introduce on the OpenSDI list to track how I wanted geoserver to grow up. Will try and hunt that down for the next email.

Idea One:
- define config needs as *normal* java beans, using bean introspection to drive any user interface concerns
- use beans as the "model" in a wicket based web application for configuration
- AOP: use spring JMX support to make these things available as JMX Beans for those running stuff like the JBoss management console
- AOP: use spring remoting to make these things available for Spring or RCP applications to configure geoserver (ie needed by my project)
- AOP: then either:
       use any bean to xml framework to produce XML blobs as needed for file storage
       or
       use any bean to xml framework to produce XML blobs as needed for database storage
       or
       use hibernate to map these beans, ensuring that the results are versioned and transactions are used to save only consistent settings
       use hsql w/ hibernate to store these beans for an out of the box geoserver deployment.

The things marked AOP would be done with spring aspect oriented support in order to have the module system provide these servies for each and every module comprising geoserver.

Cheers,"
Jody
PS. Lets stop annoying our user list with design discussion :slight_smile:

Rejoice!! Great work Alessio. I am excited to check out your work.

What is the state of the struts app on your branch. I know you did some
work figuring out how to do similar modularization with struts. The
reason I ask is because it would be nice to have the modularity with the
current app without switching to a new technology and rewriting it.

While on the topic, I spoke briefly with Simone about this and it would
nice to hear your thoughts about merging trunk and wcs branch up soon.
Simone brought up the point that it would be easiest to make the wcs
branch the new trunk, as it is has been bringing changes across from
trunk and has been much more active. Similar what we did with the 1.4.x
branch.

I know you guys are busy at the moment, as am I. So I intend to do up a
GSIP for this issue, and perhaps target its implementation for after
FOSS. Any thoughts?

-Justin

Alessio Fabiani wrote:
  

Hi guys,

after several analysis and evaluations, finally I have created an
example Web UI for GeoServer, based on wicket, which is capable to
retrieve resources directly from the classpath, in order to let each
module to have his own Web UI inside the JAR.
With this improvement we can plug-in/out modules along with theyr
interfaces into GeoServer.

The module and the template, with some examples, is alredy available for
your evaluation in the 1.4.x WCS branch.
I will wirte a detailed report describing all the evaluations and
analysis made to reach this solution (as soon as possible).

Cheers,
             Alessio.

--
-------------------------------------------------------
Eng. Alessio Fabiani
Vice President/CTO GeoSolutions

http://www.geo-solutions.it

---------------------------------------------------------
!DSPAM:1004,44e98787201111429667743!

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

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

!DSPAM:1004,44e98787201111429667743!

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

_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:1004,44e98787201111429667743!
    

5

Jody Garnett wrote:

I would like to have a steady long term solution to these issues ... so let me try an informal "grand plan slam" so the ideas are out in the open.

Basically we are moving up a list of maturity form "modules" to "plugin", this was is expected by me - but not quite so soon :slight_smile: I set up a "scale" that I tried to introduce on the OpenSDI list to track how I wanted geoserver to grow up. Will try and hunt that down for the next email.
  

Was unable to find it, produced something similar from memory and updated GEOSDEV to reflect 1.5.x being the unstable branch.
- http://docs.codehaus.org/display/GEOSDEV/Open+Web+Services+Framework