Support for vendor parameter: viewParams in WFS GetFeature requests to support GEOS-5160: http://jira.codehaus.org/browse/GEOS-5160
support for viewParams vendor parameter in GetFeature XML model
I see that you did not mark viewParams as @generated, so the manual changes you made should not be required, however, doing parsing in the EMF model sounds wrong. In GeoServer we already have a KVP parser and that should be used instead of making the model deal with a detail of the protocol (how we represent the viewparams in the request is not the business of the object model)
remove elist wrapper from model
Merge remote-tracking branch 'upstream/master' into getfeature_viewpa…
I've removed the wrapper code around EList - the model code now does nothing other then provide support for the extra field.
Hi Jeff, I had a look and it looks good but... sorry to be a pest, the files were reformatted using tabs, and the GeoTools/GeoServer coding convention says you should indent with 4 spaces, not tabs. Can you fix that?
Andrea, I started doing this but I think the upstream source has tabs instead of spaces too and the formatting is a bit wonky anyway - I think because its been generated through EMF. If I do a netbeans source reformat on the files in this pull request does that solve things for you? It would reformat the comments but they're not formatted right to start with far as I can see.
Ouch, I see now that some bits in the original files do contain tabs. The best way to go imho is to reformat them with Eclipse using the official coding convention: https://github.com/geotools/geotools/tree/master/build/eclipse
(sorry we don't have a Netbeans equivalent).
Aha, I can give that a go - I think this formatting problem has come from EMF. I had such a hard time getting it to generate the code I wanted.
Ha, I hear your pain, not a fan of EMF either.
eclipse source reformat to cleanup indentation,tabs and spaces
Hi Andrea, I've done an eclipse source reformat on the java files in this pull request. How does this look?