At 12:22 am +0100 23/2/02, Sylvain Wallez wrote:
>Hi team,
>
>Considering the discussions about the FileWritingTransformer, Cocoon
>symetry and Stefano's source/drain RT, I added in
>org.apache.cocoon.environment a new interface I already talked about :
>WriteableSource. It adds writing methods to Source's reading abilities.
Fantastic!
>Writing can occur in two ways :
>- to write SAX events, call getContentHandler() to have a consumer for
>these events,
>- to write bytes, call getOutputStream() to write them.
>
>It comes with a first implementation : FileSource, which handles (guess
>what) files. An additionnal entry in <source-handler> makes this
>implementation prevail over the default URLSource. Writing occurs with a
>simple lock mechanism that prevents simultaneous writes.
Nice to see how you have done it, much cleaner than mine ;)
>The door is now open to other implementations that will allow us to
>write anything anywhere just as Source already allows to read anything
>anywhere. Some possible implementations include xmldb (Gianugo ?), SQL
>blobs, http/ftp upload, etc.
This is going to be very cool!
>As the first implementation supports atomic updates, and some other are
>likely do support it also, I was thinking of adding a rollback() method
>on WriteableSource. But rollback is more related to the OutputStream or
>ContentHandler than to the source itself. So what do you think ?
I think we still have the problem whereby Exceptions thrown by other parts
of the pipeline can end up trashing the contents of the WritableSource,
because the SourceWriter does not know this has happened.
Is there any way rollback could be used under these circumstances?
> --o--
>
>Jeremy, I also quickly updated the FileWritingTransformer so that it
>uses any WriteableSource instead of just files.
Even better ;)
I think it needs a change of name right? Or is it even obsolete now?
WritableSourceTransformer anyone?
<source:write xmlns:source="http://apache.org/cocoon/source/1.0"/>
Or TeeSourceTransformer, TeeJointTransformer, DownTheDrainTransformer ;)
Or should something like the XInclude Transformer(s) and
WritableSourceTransformer be united into a single SourceIOTransformer that
has tags for both read and write?
<source:write src="file:/blah.xml"/>
<source:read src="dbxml:/collection/document"/>
>Could you please look at it ?
Looks like a good job to me ....
>Another update would be also to the 'serializer' parameter fully
>optional so that SAX events are sent directly to the result of
>WriteableSource.getContentHandler(). This would for avoid parsing the
>output of the serializer for native XML sources such as xmldb.
OK, I'll do this.
Just to make sure I understand what you are suggesting properly ....
If the Serializer param is supplied, I get the Serializer and give it the
OutputStream from WriteableSource.getOutputSource() and send events to the
Serializer's ContentHandler.
If no Serializer parameter exists, I instead send events directly to the
ContentHandler I get from WriteableSource.getContentHandler().
>BTW, your new slash-edit demo is really nice. By crossing this with the
>Chaperon text parser and the "crushing userland" thread, we should
>quickly have a Cocoon-powered weblog !
Ah Ha! It works ... great news!
The Chaperon text parser, can it take paragraphs of text and convert it to XML?
The user writes something like this in a form field:
Nam liber tempor cum soluta nobis eleifend option congue nihil imperdiet
doming id quod mazim placerat facer possim assum.
Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy
nibh euismod
Tincidunt ut laoreet
Dolore magna aliquam
Erat volutpat
Which is turned into something like this:
<p>Nam liber tempor cum soluta nobis eleifend option congue nihil imperdiet
doming id quod mazim placerat facer possim assum. </p>
<p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam
nonummy nibh euismod</p>
<p>Tincidunt ut laoreet<br/>
Dolore magna aliquam<br/>
Erat volutpat</p>
Can it do this?
This would avoid much of the need to let the user edit XML at all, and save
everybody a lot of grief!
Brilliant news
Thanks Sylvain
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]
