Hi,
Good point. We can compile my current branch as-is if we depend on
gt-wfs-ng as a provided dependency, but that won't stop things from
breaking at runtime. The classes that are used to define the values of
stored query parameters currently reside in gt-wfs-ng, so this would need
to be refactored for the drop-in replacement idea to work in my case.
Just to throw out some ideas:
1) The parameter classes could be moved to geoserver so they would be
available regardless if the user uses wfs or wfs-ng. This would however
place the burden of resolving the parameters into gs instead of gt-wfs-ng
and would reduce the usefulness of the stored query support in standalone
gt (i.e. without geoserver)
2) The parameter classes could be moved somewhere closer to gt core so
they would be available regardless if wfs or wfs-ng is plugged in.
3) UI code relating to the stored query configuration can be wrapped with
reflection and Class.forName() and protected so it will work regardless wfs
or wfs-ng is in use
Option 1 is less than optimal design wise as it would lessen the usefulness
of cascaded stored query sources. Option 3 would require a lot of
tip-toeing around and we would end up with somewhat dirty code. This is
especially unfortunate as this affects a core UI view. Option 2 feels best
from my view.
Thoughts? If you feel option 2 is the way to go, I'd appreciate ideas
regarding where the parameter classes should be stored in.
Sampo
On Wed, Jun 18, 2014 at 11:36 AM, Andrea Aime <[email protected]>
wrote:
> On Tue, Jun 17, 2014 at 6:36 PM, Justin Deoliveira <
> [email protected]> wrote:
>
>>
>> Cool, I think for now what I'll do is proceed with making wfs-ng a pure
>> drop in and package it up as a community module for geoserver. Along with
>> it documentation that specifies installing it requires removing the old
>> one**. And then once we are more confident with it and it has seen some
>> more user testing we can perhaps perform the switch and make it the
>> default, packaging up the original as an extension.
>>
>
> No objection personally, but I'm wondering how that will affect Sampo's
> work.
> I supposedhis pull request won't even compile if we are not depending on
> wfs-ng?
> https://github.com/geoserver/geoserver/pull/611
>
> Cheers
> Andrea
>
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/NWWaa2 for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39 339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> -------------------------------------------------------
>
--
Sampo Savolainen
R&D Director, Spatineo Oy
[email protected]
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc
This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.
------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
