You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sylvain Wallez <sy...@anyware-tech.com> on 2002/02/23 00:22:16 UTC
WriteableSource to write anywhere
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.
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.
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.
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 ?
--o--
Jeremy, I also quickly updated the FileWritingTransformer so that it
uses any WriteableSource instead of just files. Could you please look at
it ? 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.
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 !
--o--
Note : I had some problems with XConfTool to declare this new Source
factory. I had to add it in xmldb.xconf because XConfTool handles only
components items (i.e. first-level elements) and not sub-items. Is there
another way ?
Sylvain
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: WriteableSource to write anywhere
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 6:59 pm +0100 28/2/02, Sylvain Wallez wrote:
>Jeremy, could you please look at this for the SourceWritingTransformer ?
I think we just passed each other like ships in the night ;)
I'll get on to making the changes.
Thanks
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@vizzavi.net>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: WriteableSource to write anywhere
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Sylvain Wallez wrote:
> Jeremy Quinn wrote:
<snip/>
>>> 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?
>>
> After more thoughts, I will add the following methods to handle
> abort/rollback on a WriteableSource :
>
> boolean canAbort(ContentHandler ch)
> boolean canAbort(OutputStream os)
> void abort(ContentHandler ch)
> void abort(OutputStream os)
>
> This allows for transactional sources, such as the temp-file based
> FileSource of an hypothetical SQLSource. The abort method doesn't
> apply on the source only, but on the result of getContentHandler() or
> getOutputStream().
Done, using the little time I have for Cocoon this week...
The methods are called "cancel", which better means that all effects of
a ContentHandler or an OutputStream are cancelled while "abort" may mean
"keep what's been done up to now and leave it as is". Also, I didn't
want to use "rollback" which is more SQL-oriented.
Jeremy, could you please look at this for the SourceWritingTransformer ?
I also added an "boolean exists()" on WriteableSource, which it could be
well moved on Source. But is this change to the Source interface
acceptable at this time, or should we wait for a 2.1 release ?
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com http://www.apache.org/~sylvain
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: WriteableSource to write anywhere
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Jeremy Quinn wrote:
>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?
>
After more thoughts, I will add the following methods to handle
abort/rollback on a WriteableSource :
boolean canAbort(ContentHandler ch)
boolean canAbort(OutputStream os)
void abort(ContentHandler ch)
void abort(OutputStream os)
This allows for transactional sources, such as the temp-file based
FileSource of an hypothetical SQLSource. The abort method doesn't apply
on the source only, but on the result of getContentHandler() or
getOutputStream().
>> --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().
>
That's exactly what I meant : if no serializer has been specified, just
use the ContentHandler provided by the WriteableSource and let the
source do it's job directly with SAX events. If you look at FileSource,
it used an XML serializer internally, but an xmldb source that natively
stores XML won't need it.
<snip/>
Sylvain
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: WriteableSource to write anywhere
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 1:50 pm +0100 23/2/02, Stephan Michels wrote:
>On Sat, 23 Feb 2002, Jeremy Quinn wrote:
>
>> 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!
>
>#token WORD [A-Za-z]+;
>#token CR \r;
>
>#whitespace [\ \t\n]+
>
>%%
>
>linecontent : line WORD %append
> | WORD %append
> ;
>
>line : linecontent CR
> ;
>
>emptyline : CR
> ;
>
>paragraphcontent : paragraphcontent line %append
> | line %append
> ;
>paragraph : paragraphcontent emptyline
> ;
>
>text : text paragraph %append
> | paragraph %append
> ;
>
>Something like this should work, and chaperon will produce
><text>
> <paragraph>
> <line>
> <WORD>Nam</WORD><WORD>liber</WORD>
>[...]
>
Wow! Incredible looking language!
Never seen anything like it before.
>At this moment, we write in our group a latex grammar, with which
>author could write latex(inclusive mathematical content) in a webform.
nice idea
Thanks for your help
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@vizzavi.net>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: WriteableSource to write anywhere
Posted by Stephan Michels <st...@vern.chem.tu-berlin.de>.
On Sat, 23 Feb 2002, Jeremy Quinn wrote:
> >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?
I think yes.
> 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!
#token WORD [A-Za-z]+;
#token CR \r;
#whitespace [\ \t\n]+
%%
linecontent : line WORD %append
| WORD %append
;
line : linecontent CR
;
emptyline : CR
;
paragraphcontent : paragraphcontent line %append
| line %append
;
paragraph : paragraphcontent emptyline
;
text : text paragraph %append
| paragraph %append
;
Something like this should work, and chaperon will produce
<text>
<paragraph>
<line>
<WORD>Nam</WORD><WORD>liber</WORD>
[...]
At this moment, we write in our group a latex grammar, with which
author could write latex(inclusive mathematical content) in a webform.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: WriteableSource to write anywhere
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
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
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@vizzavi.net>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: WriteableSource to write anywhere
Posted by Nicola Ken Barozzi <ba...@nicolaken.com>.
From: "Bertrand Delacretaz" <bd...@codeconsult.ch>
> On Monday 25 February 2002 18:35, Sylvain Wallez wrote:
> >. . .
> > >Another argument is being able to use a CVS backend for versioning
> > >structured text documents stored in plain ASCII. AFAIK, this
> > > wouldn't work as well today with XML.
> >
> > Well, CVS doesn't really care of what's inside a versioned file ;)
> >. . .
>
> Sure but CVS diffs of plain text files are usually much better that
> diffs of XML files ;)
BTW, for nice xml diffs there is (Apache style licence)
http://www.vmguys.com/vmtools/
--
Nicola Ken Barozzi barozzi@nicolaken.com
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: WriteableSource to write anywhere
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
On Monday 25 February 2002 18:35, Sylvain Wallez wrote:
>. . .
> >Another argument is being able to use a CVS backend for versioning
> >structured text documents stored in plain ASCII. AFAIK, this
> > wouldn't work as well today with XML.
>
> Well, CVS doesn't really care of what's inside a versioned file ;)
>. . .
Sure but CVS diffs of plain text files are usually much better that
diffs of XML files ;)
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: WriteableSource to write anywhere
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Bertrand Delacretaz wrote:
>On Monday 25 February 2002 15:26, Sylvain Wallez wrote:
>
>>. . .
>>Now what are the uses cases where we don't want to write XML ? There
>>may be cases where data is sent to the user or read from the request
>>in a non-xml format (such as structured text like discussed earlier
>>about Chaperon), but won't it be stored as XML ?
>>
>
>Storing structured text as XML implies that the reverse transform (XML
>to structured text) is available, to be able to rebuild the structured
>text for later editing.
>
>But in this case, the user might find a slightly different text (due to
>the conversion roundtrip) when re-editing it later on. IMHO this speaks
>for storing structured text as is, which means being able to write
>non-XML from Cocoon.
>
Mmmh... you may be right. In the case of structured text, the whole
document can be contained in a single text node, and thus can be kept
"as is" from the user request down to the file. Then we need only a
generator for converting structured text to XML for publishing.
But in that case, I'm not sure we can actually use the
SourceWritingTransformer since it expects to write an XML document, thus
containing at least a root node enclosing a text node.
>Another argument is being able to use a CVS backend for versioning
>structured text documents stored in plain ASCII. AFAIK, this wouldn't
>work as well today with XML.
>
Well, CVS doesn't really care of what's inside a versioned file ;)
>I don't know which one of "XML to structured text transform" or "being
>able to store non-XML data" is easier, but to work with editable
>structured text one of them is needed.
>I think "being able to store non-XML data" is more general.
>
Sylvain
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: WriteableSource to write anywhere
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
On Monday 25 February 2002 15:26, Sylvain Wallez wrote:
>. . .
> Now what are the uses cases where we don't want to write XML ? There
> may be cases where data is sent to the user or read from the request
> in a non-xml format (such as structured text like discussed earlier
> about Chaperon), but won't it be stored as XML ?
Storing structured text as XML implies that the reverse transform (XML
to structured text) is available, to be able to rebuild the structured
text for later editing.
But in this case, the user might find a slightly different text (due to
the conversion roundtrip) when re-editing it later on. IMHO this speaks
for storing structured text as is, which means being able to write
non-XML from Cocoon.
Another argument is being able to use a CVS backend for versioning
structured text documents stored in plain ASCII. AFAIK, this wouldn't
work as well today with XML.
I don't know which one of "XML to structured text transform" or "being
able to store non-XML data" is easier, but to work with editable
structured text one of them is needed.
I think "being able to store non-XML data" is more general.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: WriteableSource to write anywhere
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Jeremy Quinn wrote:
>At 12:22 am +0100 23/2/02, Sylvain Wallez wrote:
>
>>Jeremy, I also quickly updated the FileWritingTransformer so that it
>>uses any WriteableSource instead of just files. Could you please look at
>>it ? 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.
>>
>Hi Silvain,
>
This is spelled "S_y_lvain" :)
>I am just working on a new Transformer, WritableSourceTransformer, that
>will replace FileWritingTransformer and should be able to write to any
>writable source.
>
>What I do not understand right now is this:
>
>How do I tell if a particular WritableSource needs the services of a
>Serializer or not?
>
>'file://' needs one, but XMLDB will not right?
>
You don't need to know it. A WritableSource must implement both
getContentHandler() and getOutputStream(). If a serializer is not
specified to the WriteableSourceTransformer, the SAX events are sent
directly to the WriteableSource, and the implementation knows if it
needs (as file:) or not (as xmldb:) to use an internal serializer.
>At the moment, I am working on the assumption that is you have provided a
>Serializer parameter, you want to use a Serializer. But I think this is not
>the best way to do it!
>
This should be the way. But you will need to provide a serializer to the
transformer only if the target storage format is not XML. In that case,
this certainly makes the assumption that the target source is byte-based
(like file) and not XML-based (like xmldb).
Now what are the uses cases where we don't want to write XML ? There may
be cases where data is sent to the user or read from the request in a
non-xml format (such as structured text like discussed earlier about
Chaperon), but won't it be stored as XML ?
Sylvain
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: WriteableSource to write anywhere
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 12:22 am +0100 23/2/02, Sylvain Wallez wrote:
>Jeremy, I also quickly updated the FileWritingTransformer so that it
>uses any WriteableSource instead of just files. Could you please look at
>it ? 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.
Hi Silvain,
I am just working on a new Transformer, WritableSourceTransformer, that
will replace FileWritingTransformer and should be able to write to any
writable source.
What I do not understand right now is this:
How do I tell if a particular WritableSource needs the services of a
Serializer or not?
'file://' needs one, but XMLDB will not right?
At the moment, I am working on the assumption that is you have provided a
Serializer parameter, you want to use a Serializer. But I think this is not
the best way to do it!
Thanks for any help.
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@vizzavi.net>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: WriteableSource to write anywhere
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 12:02 pm +0100 25/2/02, Michael Hartle wrote:
>Michael Hartle wrote:
>
>> BTW, two aspects: first of all, I find the naming of WriteableSource
>> somehow confusing; what about
>> seperating this into Source and Drain/Sink/whatsoever and changing the
>> "src" attribute into a "dest"-attribute
>> so this makes more sense and prevents accidential damage ?
>
>Ok, the latter half can be misunderstood - I meant generally changing
>"src" into "dest" when it comes to writing;
>having a "src" where I write to is misleading.
For sure.
You'd prefer:
<source:write dest=""/>
and
<source:read src=""/>
I take your point about the cachability, I guess I was wrong about that,
I'll have another look.
Thanks for your feedback
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@vizzavi.net>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: WriteableSource to write anywhere
Posted by Michael Hartle <mh...@hartle-klug.com>.
Michael Hartle wrote:
> BTW, two aspects: first of all, I find the naming of WriteableSource
> somehow confusing; what about
> seperating this into Source and Drain/Sink/whatsoever and changing the
> "src" attribute into a "dest"-attribute
> so this makes more sense and prevents accidential damage ?
Ok, the latter half can be misunderstood - I meant generally changing
"src" into "dest" when it comes to writing;
having a "src" where I write to is misleading.
Best regards,
Michael Hartle,
Hartle & Klug GbR
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: WriteableSource to write anywhere
Posted by Michael Hartle <mh...@hartle-klug.com>.
Jeremy Quinn wrote:
>While working on WritableSourceTransformer, I was going to look at making a
>SourceIOTransformer, that would have two verbs :
>
> <source:write src="" ..... />
>
> <source:read src="" ..... />
>
>What do you guys think about this?
>This is kind of the logical conclusion to the symmetry provided by the new
>WritableSource interface.
>
>It would not completely replace XInclude because it would not be able to do
>any caching (?). The transformer in the sitemap has no knowledge of what it
>
Ok, caching writing does not make sense, I guess, but caching the reads
should be possible as the source
interface contains a getLastModified()-call that should do the trick, so
this partially overlaps with XInclude.
BTW, two aspects: first of all, I find the naming of WriteableSource
somehow confusing; what about
seperating this into Source and Drain/Sink/whatsoever and changing the
"src" attribute into a "dest"-attribute
so this makes more sense and prevents accidential damage ?
Best regards,
Michael Hartle,
Hartle & Klug GbR
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: WriteableSource to write anywhere
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 12:22 am +0100 23/2/02, Sylvain Wallez wrote:
>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.
While working on WritableSourceTransformer, I was going to look at making a
SourceIOTransformer, that would have two verbs :
<source:write src="" ..... />
<source:read src="" ..... />
What do you guys think about this?
This is kind of the logical conclusion to the symmetry provided by the new
WritableSource interface.
It would not completely replace XInclude because it would not be able to do
any caching (?). The transformer in the sitemap has no knowledge of what it
is going to be asked to do (read or write) or on which resource, this would
be for completely dynamic operations I imagine.
What do you think?
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@vizzavi.net>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: WriteableSource to write anywhere
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Gianugo Rabellino wrote:
> Sylvain Wallez wrote:
>
>> 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.
>
> Cool stuff Sylvain!
Thanks.
>> 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.
>
> I will take a look at it ASAP, I promise :-) Still, I'm a bit confused
> about the idea of writable URLs... how can you tell, given just a URL,
> when it's supposed to be a writable object or just a readable one?
This cannot be known with the URL alone, but with the Source object :
Source src = resolver.resolve(uri);
if (src instanceof WriteableSource) {
ContentHandler ch = ((WriteableSouce)src).getContentHandler();
...
}
Sylvain
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: WriteableSource to write anywhere
Posted by Gianugo Rabellino <gi...@apache.org>.
Sylvain Wallez wrote:
> 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.
Cool stuff Sylvain!
> 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.
I will take a look at it ASAP, I promise :-) Still, I'm a bit confused
about the idea of writable URLs... how can you tell, given just a URL,
when it's supposed to be a writable object or just a readable one?
Hmmm... have to think about it.
Ciao,
--
Gianugo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org