On Tue, Jul 3, 2012 at 8:22 AM, Andrea Aime <[email protected]>wrote:
> 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?)
>
I will fully admit if I was looking at implementing the ows service / xml
parsing architecture from scratch today in a green field i would probably
avoid the use of EMF. But my opinion is that we are so far into it that we
can't avoid it for some services (like WFS) that have already chosen to go
that way.
>
>
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).
>
I'll agree it is pretty easy when things don't change among specification
versions. Going from filter 1.0 to filter 1.1 was trivial yes. But not so
trivial to implement the new functionality for filter 2.0 that involved
adding the temporal filter classes and everything for joining. I don't have
exact times available but that in itself was weeks of work. It was
certainly much more work than generating out the entire wfs 2.0 schema
model and using the emf xml parse bindings to basically (with a few
exceptions) request/response parsing for free.
> 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.
>
A few years back I documented in what I thought was pretty good detail how
to instrument an emf object model for geotools. This used to live in the
confluence developer guide but for the life of me i can't find it now, in
confluence or the new sphinx docs for geotools.
>
> 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?
>
Happy to do so. I will start by asking Jody how to resurrect that doc i
wrote a while back.
>
> 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
>
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
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
