Make sense.
Jody Garnett
On Wed, Jul 30, 2014 at 1:12 PM, Andrea Aime <[email protected]>
wrote:
> 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
