You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by gelo1234 <ge...@gmail.com> on 2012/12/07 20:24:59 UTC
Re: zip-archive generator (reverse of zip-archive serializer)
I don't know about your use-case of zip-archive usage, but it looks like a
typical Data Integration scenario.
Perhaps you should take a look at Apache Camel:
http://camel.apache.org/zip-dataformat.html
Greetings,
-Greg
2012/12/7 Robby Pelssers <Ro...@nxp.com>
> Hi guys,
>
> Not sure if we have a zip-archive generator already
> http://cocoon.apache.org/2.1/userdocs/ziparchive-serializer.html
>
> but it would be very cool to have one. Let me explain the use case:
>
> <!--
> {1}: a URI pointing to a zip containing XML documents
> -->
> <map:match pattern="processzip/**">
> <map:generate src="{1}" type="zip"/>
> <map:transform src="processfiles.xslt"/>
> Now a lot of options
> - write results to disk
> - just serialize result
> - zip transformed files again
> ...
> </map:match>
>
> So what should this ziparchive generator do? It should let us peak into
> the ziparchive and return URI's for all entries
>
> <zip:archive xmlns:zip="http://apache.org/cocoon/zip-archive/1.0">
> <zip:entry
> name="jar:file:/C:/data/productinformation.zip!/products/PH3330L.xml"/>
> ...
> <zip:entry name="jar:file:/C:/data/
> productinformation.zip!/packages/SOT669.xml"/>
> ...
> </zip:archive>
>
> Or
>
> <zip:archive xmlns:zip="http://apache.org/cocoon/zip-archive/1.0">
> <zip:entry name="jar:
> http://www.mydomain.com/data/productinformation.zip!/products/PH3330L.xml
> "/>
> ...
> <zip:entry name="jar:
> http://www.mydomain.com/data/productinformation.zip!/packages/SOT669.xml"/>
> ...
> </zip:archive>
>
>
> So if you add a transformer in that pipeline you can use the XSLT document
> function to fetch the documents and process them individually.
>
> I'm only not sure about how to implement this efficiently. I don't want
> to make requests in case of a HTTP URI:
> - 1 used by the ziparchive-generator to produce the XML above
> - 1 request per invocation of the document function
>
> So maybe caching can resolve this or are there better options?
>
> Robby
>