On Wed, Jul 30, 2014 at 9:56 PM, Jody Garnett <[email protected]>
wrote:
>
>
>> To be clear, my objective is to make it possible to add more PPIOs
>> without having to register
>> them one by one in the app context (and have to know in advance what they
>> are), I have
>> no scope to redesign the way PPIOs are working, are looked up, or the
>> functionality
>> they expose, I just want to declare their existence to the current code.
>>
>
> See start of my comments: *"my ideas bash around the edge of your problem
> in order to determine scope.*"
>
> In this case I was trying to write down your requirement: "We need to
> tell apart xml/text/binary formats (as they need to be implement different
> base classes)"
>
> I had two ideas on the table for that - what did you have in mind?
>
My sentence had nothing to do with telling apart PPIOs, they can be told
apart already as they
have separate base classes, what we need
to tell apart is what the WFS output format being wrapped is producing,
either binary, text or GML,
so that we can wrap it in the appropriate PPIO wrapper class.
(and/or the ogr generated formats, if those are wrapped instead).
The sentence was:
"so we either add something to the WFS output formats telling us
which one is what, or in the case of ogr2ogr, add something in the
ogr2ogr configuration
to state what type of output we are generating (uh, in the case of XML we
might
even have to roll custom xml encoder delegates... so we'd need a factory
for those as well...)"
In more detailed terms, if we go the wfs output format wrapping
approach, WFSGetFeatureOutputFormat
would need to expose a new method:
getOutputNature(): OutputNature
where OutputNature would be and enumeration with values:
* XML (e.g., GML),
* Text (e.g. csv/json),
* Binary (e.g., shape-zip).
If instead we go for the approach of wrapping specifically the ogr2ogr
generated output formats (instead
of trying to expose each and every wfs output format as a PPIO), it would
be the just the OgrFormat class to have to expose the above method.
Another approach could be to have some sort of "registry" of mime types
that maps the mime type
to its nature (or some set of heuristics), the upside is that the exisiting
wfs output format
API would not have to be touched, the downside is that it would make it
difficult to those
adding output formats via OGR (user generated, instead of added by a
programmer) to control
the exact PPIO type associated.
Makes sense?
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
-------------------------------------------------------
------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls.
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
