At 7:28 pm +0100 8/2/02, Sylvain Wallez wrote:
>Vadim Gritsenko wrote:
Poor man's CMS, I like that ;)
>>Preamble: I do remember we had talks about inward flows, etc... Then
>>somebody (sorry, already forgot who it was) wrote about transformer
>>
>This is Jeremy Quinn ([EMAIL PROTECTED]), the author of the FP taglib on
>Cocoon 1. He's currently looking for a simple way to store XML input by
>the user, to allow in-browser document edition.
I just managed to get the first version to compile, late last night; not
tried to run it yet (I am a bit tied up today).
It is called FileWritingTransformer, it is based heavily on
XMLDBTransformer (thanks Vadim for a great example ;).
Definition:
<map:transformer name="tofile"
src="org.apache.cocoon.transformation.FileWritingTransformer">
<map:parameter name="serializer" value="xml"/>
</map:transformer/>
Invocation:
<map:transform type="tofile">
[<map:parameter name="serializer" value="xml"/>]
</map:transform>
Input document example:
<page xmlns:xfwt="http://apache.org/cocoon/xfwt/1.0";>
...
<xfwt:write src="context://doc/editable/my.xml" [serializer="xml"]>
<page>
XML Object body
</page>
</xfwt:write>
...
</page>
Output document example:
<page xmlns:xfwt="http://apache.org/cocoon/xfwt/1.0";>
...
<xfwt:write src="/actual-path/to/context/doc/editable/my.xml"
result="success|failure" serializer="xml">
[failure message]
</xfwt>
...
</page>
You give the Transformer the name of a Serializer (previously set up in the
Sitemap) that you want it to use.
The Serializer can be set in 3 places depending ion requirements,
Definition, Invocation or in the xml stream. All these config options look
like FS, but while I am working out how best to use it, I thought I would
leave them all in.
The point is, that the stream could contain any number of fragments to
write to files, they should each be able to use a different Serializer if
required.
One last thing, I wrote the Transformer with the assumption that it should
not be able to create new files, just overwrite old ones.
I felt if you need new files created then you would write an Action to do
this (from a Template maybe).
My idea was that by simplifying things in this way, it would be more likely
that this component could meet generic needs. If people want to 'lock'
files during editing, or make a backup of a file before overwriting, then
this is an application issue that can be handled by Actions.
The next class I have planned will be a Configurable Generator, very much
like the RequestGenerator, but can optionally parse the contents of
individual Form Fields (depending on the config) into the Stream, so that
XML can be edited in different form fields.
Only thing that is still bugging me about this ..... I remember from the FP
days, when you send XML out in Form Fields to the Browser via the HTML
Serializer, any tags in your XML that have (unclosed) HTML equivalents
(like <br/>, <hr/>, <li/> etc.) get messed up by the Serializer!!
Code should be on it's way in a couple of days (I'll stick it in Scratchpad?).
Suggestions welcome!
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<mailto:[EMAIL PROTECTED]> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pager:[EMAIL PROTECTED]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
