On Wed, 2009-03-25 at 16:50 +0100, Andrea Aime wrote:
> David Winslow ha scritto:
...
> > 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!)
I think some wires have been crossed here. I was thinking of
parameterizing this method from DecorationLayout.java:
private static Decoration getDecoration(String name) {
Object o = GeoServerExtensions.bean(name);
if (o instanceof Decoration) {
return (Decoration) o;
}
return null;
}
so the new call would be
GeoServerExtensions.bean(name, Decoration.class)
Another thought I had would be to create an ExtensionInfo class that we
could use for extension points. When I was just thinking of it as
having a name:
public class ExtensionInfo {
String name;
Class extension;
public Object getInstance() { return extension.newInstance(); }
}
It didn't seem to add much to what spring provides. But being able to
group by class is something that would be nice for reporting purposes as
mentioned. If we wanted, we could eventually add name-based
configuration of extensions (so you can enable/disable extensions
without moving jars around, potentially even without restarting
geoserver).
This second approach seems more like what you were thinking.
--
David Winslow
OpenGeo - http://opengeo.org/
------------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
