David Winslow wrote:
> 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)
I am not sure I see the big win here... Spring bean names are unique no?
So either way you are going to have to do a check after the fact. In
this case for null... in the other case if it is of the desired type...
6 in one, half dozen in the other.
In general imo looking up beans directly by name should be discouraged.
IN some cases I realize it is necessary, but those cases we are 100%
what the type of the class is, things like Catalog, etc...
The pattern for extension points should really to iterate over all that
around. If you are looking up one by name there is an assumption about
it at which point it is no longer an extension point.
Sorry if I am missing something there... perhaps if you could re-iterate
the use case for this method?
>
> 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(); }
> }
>
One thing i have thought about is adding a sort of "plugin" class. Each
module in geoserver would have one of these classes. Sort of like how
eclipse plugins work. Let's call it PluginInfo. I could see PluginINfo
returning a list of ExtensionInfo, etc...
But I have always thought it was overkill for how things are today. I
could be wrong and convinced otherwise though. I am just still missing
something in the use case.
> 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
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
