Hi all,
I would like to do some cleanup in the wms module. Currently, every KvpRequestReader and XmlRequestReader take an instance of WMService, subclasses for each operation: GetMap, GetFeatureInfo, etc... Same goes for each Request object as well.
Now this was done mostly for the old dispatcher, the old dispatcher needed a reference to the servlet that was handling the operation. However the way things work now, this is unecessary.
If you look at every usage of these objects, they are used only as a middleman to the underlying service configuration object, org.geoserfver.global.WMS in this case. So I would like to clean it up a bit and just have these objects take the service configuration object directly.
My rationale here is to make it easier to call wms operations programatically (the for geosearch stuff). Currently the code would have to recreate the WMService instance (which is a servlet) which is kind of a pain. Especially since there is no reason to have the middleman.
So, any objections? This is purely mechanical and wont change any behavior. Although it affects many classes which is why i want to run it by the devel team first.
Also, same would apply for wcs module as well.
-Justin
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com
Justin Deoliveira ha scritto:
Hi all,
I would like to do some cleanup in the wms module. Currently, every KvpRequestReader and XmlRequestReader take an instance of WMService, subclasses for each operation: GetMap, GetFeatureInfo, etc... Same goes for each Request object as well.
Now this was done mostly for the old dispatcher, the old dispatcher needed a reference to the servlet that was handling the operation. However the way things work now, this is unecessary.
If you look at every usage of these objects, they are used only as a middleman to the underlying service configuration object, org.geoserfver.global.WMS in this case. So I would like to clean it up a bit and just have these objects take the service configuration object directly.
My rationale here is to make it easier to call wms operations programatically (the for geosearch stuff). Currently the code would have to recreate the WMService instance (which is a servlet) which is kind of a pain. Especially since there is no reason to have the middleman.
So, any objections? This is purely mechanical and wont change any behavior. Although it affects many classes which is why i want to run it by the devel team first.
No problem on my side. +1
Cheers
Andrea
cool, plase do, +1
Gabriel
On Thursday 03 April 2008 06:41:39 pm Andrea Aime wrote:
Justin Deoliveira ha scritto:
> Hi all,
>
> I would like to do some cleanup in the wms module. Currently, every
> KvpRequestReader and XmlRequestReader take an instance of WMService,
> subclasses for each operation: GetMap, GetFeatureInfo, etc... Same goes
> for each Request object as well.
>
> Now this was done mostly for the old dispatcher, the old dispatcher
> needed a reference to the servlet that was handling the operation.
> However the way things work now, this is unecessary.
>
> If you look at every usage of these objects, they are used only as a
> middleman to the underlying service configuration object,
> org.geoserfver.global.WMS in this case. So I would like to clean it up a
> bit and just have these objects take the service configuration object
> directly.
>
> My rationale here is to make it easier to call wms operations
> programatically (the for geosearch stuff). Currently the code would have
> to recreate the WMService instance (which is a servlet) which is kind of
> a pain. Especially since there is no reason to have the middleman.
>
> So, any objections? This is purely mechanical and wont change any
> behavior. Although it affects many classes which is why i want to run it
> by the devel team first.
No problem on my side. +1
Cheers
Andrea
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplac
e _______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:4045,47f508e6112891096210785!