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.
------------------------------------------------------------------------------
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
