MapContent is advertised in the docs as the class to use in preference to MapContext for new development. The attached patch does the following:
- adds setMapContent and getMapContent methods to GTRenderer and StreamingRenderer
- replaces the MapContext instance in StreamingRenderer with a MapContent instance
- deprecates setContext and getContext methods
|Introduce StyleLayer to allow Renderer to grab SLD||Resolved|
|Introduce RasterLayer abstract class||Resolved|
|Handling of getBounds() and AreaOfInterest()||Closed|
|MapViewport handling of AffineTransform and ScreenArea||Closed|
|Layer to support methods expected by Renderers||Closed|
[ Hey guys - I am going to try something. I am worried that I have been too pig headed about this. The real motivation for Layer was to make the constructors make sense - not to make Andrea's life difficult. I think with my object-oriented hat on, wanting each class to have a minimal responsibility, I have made things too difficult / risky.
I am going to look at pulling the getStyle() and getFeatureSource() and getQuer() methods up into Layer (and having them return "empty" content). I can explain in the javadocs that these methods are used by feature based renderers; and the default implementation only needs to be overridden if your Layer has something to say.
I would hope this would avoid the amazing amount of casts witnessed in Andrea's and Micheal's patches. I don't think it impacts on the clarity of the interfaces; the constructors are still clear; we still have concrete implementations each of which has their own specific "workarounds" for providing a FeatureSource - and since it is not tired up in conditional code I hope it would be readable. ]
|Status||Open [ 1 ]||Resolved [ 5 ]|
|Resolution||Fixed [ 1 ]|