And to clarify these (and my previous feedback) are suggestions, even
though they came off as demands previously. I have no strong argument if
they don't make sense from your point view.
On Thu, Oct 25, 2012 at 6:46 PM, Justin Deoliveira <[email protected]>wrote:
> Sounds good. Just a note on naming consistency on transform vs
> transformation in the class names, filenames, rest api, etc... i would vote
> for the shorter :)
>
>
> On Thu, Oct 25, 2012 at 9:20 AM, Andrea Aime <[email protected]
> > wrote:
>
>> Hi,
>> wanted to recap a bit the XSLT module basics before starting to code it.
>>
>> So, as we said in precedence, XSLT will be a WFS output format generator
>> like
>> the ogr module.
>> The basic needs are to have server wide output formats generated like that
>> (which would be thus independent of the GML contents being transformed),
>> community feedback demanded it to have a per layer too, which makes sense
>> since transformations might need to pick on specific attributes as well.
>>
>> Configuration wise, we'll store the xml config files in
>> $DATA_DIR/wfs/xslt,
>> using an approach similar to the one of the styles, that is, two files for
>> each transform:
>>
>> - myTransform.xslt
>> - myTransform.xml
>>
>> where myTransform.xml will be a XStream dump of a TransformationInfo
>> object
>> (which looks like a CatalogInfo object in case in the future we want
>> to make this core).
>> The xml file will contain:
>>
>> <TransformationInfo>
>> <sourceFormat>text/xml; subtype=gml/2.1.2</sourceFormat>
>> <outputFormat>text/plain</outputFormat>
>> <fileExtension>txt</fileExtension>
>> <fileName>myTransform.xslt</fileName>
>> </TransformationInfo>
>>
>> whereas a transformation specific to a feature type will look like:
>>
>> <TransformationInfo>
>> <sourceFormat>text/xml; subtype=gml/2.1.2</sourceFormat>
>> <outputFormat>text/plain</outputFormat>
>> <fileExtension>txt</fileExtension>
>> <fileName>myTransform.xslt</fileName>
>> <featureType>
>> <id>FeatureTypeInfoImpl-47cc14ea:13942f810c2:-8000</id>
>> </TransformationInfo>
>>
>> in order to link to the layer in a way that's layer rename safe.
>>
>> REST wise we'll allocate the transformations in:
>>
>> /rest/wfs/transformations/<myTransformation>
>>
>> Justin suggested we should also have transformations under a feature type
>> if they are related to it:
>>
>> /rest/workspaces/.../featureTypes/<featureType>/<myTransformation>
>>
>> I can go for this as well, although I'm a bit worried about performance,
>> to do this operation we'll have to scan all configuration files in order
>> to determine which ones are related to a particular layer, if any
>> I also guess that under this setup the layer specific transformations
>> would
>> not appear at the top level... or not?
>>
>> Perf wise we could keep a cache of the config files in memory, and just
>> scan the file system to determine which xml files are there, so that
>> we avoid reloading them often.
>>
>> All good?
>>
>> Cheers
>> Andrea
>>
>> --
>> ==
>> Our support, Your Success! Visit http://opensdi.geo-solutions.it 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
>>
>> -------------------------------------------------------
>>
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_sfd2d_oct
>> _______________________________________________
>> Geoserver-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>
>
>
> --
> Justin Deoliveira
> OpenGeo - http://opengeo.org
> Enterprise support for open source geospatial.
>
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
