On Tue, Jul 3, 2012 at 4:04 PM, Justin Deoliveira <[email protected]>wrote:
>
>
> On Tue, Jul 3, 2012 at 7:20 AM, Andrea Aime
> <[email protected]>wrote:
>
>> On Tue, Jul 3, 2012 at 2:55 PM, Justin Deoliveira
>> <[email protected]>wrote:
>>
>>> Sounds like a great addition to me to me. Is the plan to only support
>>> the time/elevation parameters in GET requests like WMS or also handled via
>>> POST? I ask because POST request parsing often gets overlooked (like with
>>> viewParams).
>>>
>>
>> Indeed, only with GET, modifying the EMF bindings to add vendor params is
>> something I want to avoid at all costs, doing the mixed approach has
>> been discussed on jira but it's not trivial either (it seems it would go
>> though
>> a EMF modification too, ugh):
>> http://jira.codehaus.org/browse/GEOS-5160
>>
>
> I think this is pretty limiting with WFS where POST requests are much more
> common than with WMS.
>
> If updating the object model is so hindering then we need to figure out
> what an acceptable alternative is since because imo just adding the GET
> bindings for WFS is not really an option. I have ran into a few cases of
> people being confused about "vendor" functionality only being available in
> GET requests. I don't even believe this is documented anywhere.
>
The documentation only shows GET requests, never POSTS, but indeed it does
not tell these vendor options
are not available in POST requests. That would be easy to fix though.
As for a better way, I don't know, the obvious one to me would be not using
EMF and use plain java beans
that everybody knows how to modify, but we're too far in to escape it
without a seriously major investment
(thought we should probably consider not developing EMF models for new
specs we implement, but
try something different, maybe plain java beans with annotations to
compensate for the info we cannot
retrieve via reflection?)
To give you a comparison, see how "easy" it has been to upgrade the filters
along their evolution,
while for WFS we need to have different EMF models and proxy classes that
hide the differences,
which is imho ugly (but necessary).
Modifying a model in EMF is a russian roulette, can take a few hours or
days, it depends on having
the right version of Eclipse with the right version of EMF in it (that is,
the one that was used to
generate the model in the first place, which is often not known), there are
a few ways to do it
but none is documented afaik.
The only person I know that can do it right relatively quickly and in a
consistent way is you,
I honestly don't remember where to start the one time a year I have to put
my hands on it.
Given that we cannot escape EMF for WFS without a major investment, maybe
you could
upload somewhere a version of Eclipse that is known to work with our
current bindings,
and document a single way to do model modifications?
Cheers
Andrea
--
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
