David Winslow ha scritto: > While working on this, I've come across a few questions that I'd like to > bring to the list. > > 1. legend_options seems to not be working on 1.7.x SVN. I haven't > investigated too deeply. Justin mentioned that Simone has been doing > some work on the legends, so maybe he would have a better idea where to > look. > > 2. When I try to access the title of a layer via MapLayer.getTitle(), I > get the qualified name instead. (the MapLayers are coming from a > WMSMapContext). Is this the intended behavior?
I guess the title was never really used, and filled just to make the code happy. What do you expect, the title configured in the FeatureType config panel? > 3. The GetLegendGraphic code works by generating a bunch of > BufferedImages, then stitching them all together at the end. Since my > layout code sometimes squishes components to fit in the tile, I redid > the legend renderer to render to a single graphics context (which can > render the fonts directly on to the image so they don't become > unreadable when scaled). Is there interest in bringing this back to > DefaultRasterLegendProducer? (Should be about 50% savings in memory for > getlegendgraphic requests; I don't think there's a correctness issue > here.) Seems like a good idea, just double check with Simone if this can hinder anyway the raster legend code. > 4. The extension point for the decorations feels a lot like the > regionating strategies (maybe I'm just not sufficiently creative.) > Rather than reproducing RegionatingStrategyFactory, I was thinking we > might want to do something more general. Hmm... the meaning seems completely different thought? What would be the general interface name? StrategyWithAName? :-) (kidding, but the question about how to make this general but still meaningful remains). > In particular, I was thinking we could just overload > GeoServerExtensions.bean() with a function that takes a name and a class > and returns null if the bean found is not of the expected class. For > type-safety concerns, we can configure the beans such that Spring > creates a new instance every time the bean is requested. Oh, right, that sounds a lot like functional programming (passing in a function? Have we switched to Scala while I was not looking? That's probably a switch I would not complain about ;-) ). Seriously, yeah, we can pass in an interface with a single method and it would work. I guess the only issue I'm seeing is that Mike request to enumerate the installed extension points, in order to know what plugins are available in a certain GeoServer install. If we go down the "function filter" path, we still need a way to enumerate _and_ classify what's out there, in terms of: - this is a WFS/WCS/WMS output format - that is a datastore - this is a kml regionation strategy - and oh, these are the map decoration we have (annd you can write your own, too!) Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
