Jody Garnett ha scritto:
Andrea Aime wrote:
Hi,
I've just written a document that explains how we could use Spring
and what advantages we would get by using it, along with a modules proposal
on http://docs.codehaus.org/display/GEOSDEV/Spring+proposal.
Thanks for the clear writing Andrea.
It would be very nice if people could read, evaluate, discuss, fix, comment it,
even on here on the mailing list.
Module breakdown (Sorry for the extra detail, for discussion only):
- Main - check
- Configuration - check
- Security-basic - check
- WFS - check
- WMS - check
- WMS-xxx-handler: maybe "handler" should be format? Other options for plugability...
-- explicitly extend by request type (version negotiation) - isolate WMS_1_0, WMS_1_1 and so on....
-- format types, extend for GIF, JPEG, SVG etc... (aka your example)
-- protocol (is this already covered by Main - SOAP, OWS, etc...)
- Webapp: this would be the program that would bind everything together?
Yes, the binding really just means searching in all the jars for the
spring.xml files and build a context out of them (and this is done by
a 3 lines declaration inside the web.xml file).
Aka a geoserver based application (like the WCS prototype) would make a new one of these?
A Geoserver based application could decide to write a new one of these, yes.
Yet, for a WCS prototype, why not just add a new module, which should contain
also its web user interface, and plug it with the rest?
Do you see now why I was asking about putting web pages in the classpath?
If we can do that, all you really need to do to build your customized geoserver
is to put the jars inside an empty web application.
If possible I would like to keep the idea of "data" module, and as with GeoServer 1.3.x to handle connections to data stores etc...you could call this catalog (but that would get confusin), resources may may be better then "data"...
Hmm... I thought this stuff was handled by the configuration objects.
Can you point me to the classes that would make up this "data" module?
For the web interaction pages, I always thought each module should provide its own configuration ui, and the bean for the module should indicate the url on which that service is available... Could easily reproduce the current conventions of wfs/config, wms/config, data/config
Yes, that was more or less the idea. The only problem is that if the ui
is made of jsp pages we would need to have the modules structures as follows:
module
-- src
-- webapp
----WEB-INF
------module-xxx-struts-config.xml
----page1.jsp
----page2.jsp
And then have some build time routine that takes the "webapp" of each
module and merges them. What I don't like about this approach is that
it makes testing difficult, because you have a build in the middle, you
can't just run some executable from inside your IDE (for a normal
web application we can run Jetty from inside the IDE, but for a modularized
one made with struts, we first need to merge the various modules contributions).
Of couse, with a different framework we won't need to (for example, using Wicket
you don't need to, web pages just stay in the classpath, and you can even
declare pages entry points inside a Spring configuration file because the latest
Wicket has native Spring integration).
Yet, I understand I can't ask people to go thru such a change (architecture and
web framework at the same time).
Cheers
Andrea