You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Jeremy Quinn <je...@media.demon.co.uk> on 2002/02/15 11:35:24 UTC
FileWritingTransformer
Dear All,
I reckon I have the FileWritingTransformer and some samples ready for
others to test.
Would anyone have any objection to me adding them to the scratchpad?
I have chosen an Apache Namespace for it:
xmlns:xfwt="http://apache.org/cocoon/xfwt/1.0"
Is there any objection to this?
What does it do?
Put this in a document that gets transformed by the FileWritingTransformer:
<xfwt:write src="docs/result1.xml">
<page>
<title>FileWritingTransformer Test Result 1</title>
<content>
<para>Congratulations!</para>
</content>
</page>
</xfwt:write>
It creates the file with the <page/> as root element.
--
___________________________________________________________________
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: FileWritingTransformer, locking
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
On Monday 18 February 2002 11:37, Jeremy Quinn wrote:
>. . .
> While I am working out how to do this the right way, I'll fix the
> Transformer so that it writes to a temporary file as above, and if
> another person attempts to simultaneously overwrite, I can just throw
> an Excpetion and have them try again later. I would like to work out
> how to do this properly though ;)
>. . .
If you can force the temporary filename to be a unique mapping of the
filename that you're writing, then just detecting its existence will
tell you that another user is already writing to the same file. This
gives you a nice "optimistic locking" that will be sufficient in most
cases I think.
Maybe the File.createTempFile method will help you here.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: FileWritingTransformer, locking
Posted by Stefano Mazzocchi <st...@apache.org>.
Bertrand Delacretaz wrote:
>
> On Saturday 16 February 2002 14:27, Jeremy Quinn wrote:
> >. . .
> > I suspect I ought to be Serialising into a temporary file and
> > replacing the original only after everything has worked.
>
> Makes sense, AFAIK renaming a file is an atomic operation on all
> current OSes.
yes, well, at least you don't get problems if two users are renaming the
same file since the OS synchronizes them.
> >. . .
> > How do I block the process of a second simultaneous request?
> > Do I 'syncronize' the temporary file?
>
> If you want to do this in memory (which makes sense in your case I
> think), you have to have all instances of your component synchronize on
> a shared java object that maps to the absolute filename of the
> file you're writing.
>
> One problem in this case is making sure the lock on your file is
> released if the file writing operation fails, probably using a lock
> validity timeout .
>
> In a monolithic program you'd create a Singleton component (a static
> single-instance object) to handle such locks. I suspect such mechanisms
> already exist in Avalon, but I'm not familiar enough with it to tell
> you where to look. Maybe some Avalon guru can help you here?
Hmmm, I would go like Jeremy proposed: write on a temporary file (make
sure you add a timestamp somewhere or people might hit the same problem
with the temporary file.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: FileWritingTransformer, locking
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 8:15 am +0100 18/2/02, Bertrand Delacretaz wrote:
Thanks for your reply, Bertrand,
>On Saturday 16 February 2002 14:27, Jeremy Quinn wrote:
>>. . .
>> I suspect I ought to be Serialising into a temporary file and
>> replacing the original only after everything has worked.
>
>Makes sense, AFAIK renaming a file is an atomic operation on all
>current OSes.
That's good to hear ...
>>. . .
>> How do I block the process of a second simultaneous request?
>> Do I 'syncronize' the temporary file?
>
>If you want to do this in memory (which makes sense in your case I
>think), you have to have all instances of your component synchronize on
>a shared java object that maps to the absolute filename of the
>file you're writing.
>
>One problem in this case is making sure the lock on your file is
>released if the file writing operation fails, probably using a lock
>validity timeout .
>
>In a monolithic program you'd create a Singleton component (a static
>single-instance object) to handle such locks. I suspect such mechanisms
>already exist in Avalon, but I'm not familiar enough with it to tell
>you where to look. Maybe some Avalon guru can help you here?
Thanks for your suggestions.
While I am working out how to do this the right way, I'll fix the
Transformer so that it writes to a temporary file as above, and if another
person attempts to simultaneously overwrite, I can just throw an Excpetion
and have them try again later. I would like to work out how to do this
properly though ;)
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: FileWritingTransformer, locking
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
On Saturday 16 February 2002 14:27, Jeremy Quinn wrote:
>. . .
> I suspect I ought to be Serialising into a temporary file and
> replacing the original only after everything has worked.
Makes sense, AFAIK renaming a file is an atomic operation on all
current OSes.
>. . .
> How do I block the process of a second simultaneous request?
> Do I 'syncronize' the temporary file?
If you want to do this in memory (which makes sense in your case I
think), you have to have all instances of your component synchronize on
a shared java object that maps to the absolute filename of the
file you're writing.
One problem in this case is making sure the lock on your file is
released if the file writing operation fails, probably using a lock
validity timeout .
In a monolithic program you'd create a Singleton component (a static
single-instance object) to handle such locks. I suspect such mechanisms
already exist in Avalon, but I'm not familiar enough with it to tell
you where to look. Maybe some Avalon guru can help you here?
--
-- Bertrand Delacrétaz, www.codeconsult.ch
-- web technologies consultant - OO, Java, XML, C++
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: FileWritingTransformer
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 11:53 pm +0100 15/2/02, Stefano Mazzocchi wrote:
>Jeremy Quinn wrote:
>
>> >Question 1#: how hard would it be do to
>> >
>> > <xfwt:write src="xmldb://localhost/result.xml">
>> > <page>
>> > ...
>> > </page>
>> > </xfwt>
>>
>> Currently there is a load of code in FileWritingTransformer that is File
>> specific, I check for a 'file:' prefix on resolved sources.
>>
>> I think we would want Sylvain's WriteableSource would'nt we?
>
>Yes, I definately think we should go down this road.
Good.
I agree .... Silvain, are you reading this?
Where do we start?
>> As I understand it we would need stuff like:
>>
>> WriteableXMLDBSourceImpl, WriteableFileSourceImpl etc.
>>
>> Or use/extend Vadim's XMLDBTransformer?
>
>I'm afraid of having a bunch of different transformers that react on
>different namespaces just because the storage location is different.
I was not too worried about that myself, but if it is an issue for others,
then that's fine by me.
I thought you would have trouble with XMLDBTransformer due to XUpdate ...
>I think that a writable resource would make perfect sense.
>
>> >Question #2: do you check if the <xfwt:write> element includes *one* and
>> >only *one* nested element? If not, we could end up with problems later
>> >on.
>>
>> No I don't, I'll add that to my list, thanks.
>
>'welcome.
Can't immediately work out how to do it, though I am sure it will come or me ;)
>> Two other issues ....
>>
>> I need to make sure the Transformer does not emit more than one 'copy' of
>> each namespace prefix, currently multiple sources (FileGenerator &
>> XInclude) with multiple copies of the same namespace, cause multiple
>> identical xmlns attributes in the Serialized file, causing subsequent
>> Parser errors when it is read.
>>
>> A namespace declaration for xfwt is always output to the files it writes to.
>> It was already in the Document that the file is generated from so it
>> happens automatically.
>>
>> I am trying to decide if this is a good thing or not.
>>
>> In one way it is quite cute ;) a kind of signature, but in another sense it
>> is pollution, if there are no xfwt tags in the file, why the hell should it
>> declare that namespace?
>>
>> If I filter it out however, then no-one can edit files containing that
>> namespace anymore.
>
>Congratulations: you win the price of 'first man on cocoon-dev to crush
>into the wall of meta-namespacing' :)
ROFL!
>Really: this is a *very* big issue and it is somewhat similar to way
>XSLT is capable of performing namespace virtualization in order to allow
>stylesheets to work on stylesheets.
>
>But this is a *very* complex thing and always smelled like FS to me.
>
>I would personally filter out all the content of the 'xfwt' namespace
>before saving and in case people has to write content that includes a
>'turned-off' 'xfwt' content (say, an XML document that explains the
>'xfwt' markup), that could be written in CDATA sections.
>
>> Which is the right way to go do you think?
>
>I would filter them out before saving and forget about it.
Fair enough!
I'll get that done.
I am also going to gradually grow the 'editor' samples.
I was originally hoping that the 'editor' sub-sitemap would work as a
sub-sitemap of the sitemap whose content you wanted to edit. (Phew!).
ie. you want to make your project editable, you add the editor sub-sitemap
to it, modify the stylesheets to match your document structure and bingo!
I am not sure this will work however, a child SiteMap has no way of
determining the actual location that the parent uses to store it's files
right? So it would have to be hard coded .... not nice ....
Maybe I am not thinking straight ....
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: FileWritingTransformer
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Stefano Mazzocchi wrote:
>Jeremy Quinn wrote:
>
>>>Question 1#: how hard would it be do to
>>>
>>><xfwt:write src="xmldb://localhost/result.xml">
>>> <page>
>>> ...
>>> </page>
>>></xfwt>
>>>
>>Currently there is a load of code in FileWritingTransformer that is File
>>specific, I check for a 'file:' prefix on resolved sources.
>>
>>I think we would want Sylvain's WriteableSource would'nt we?
>>
>
>Yes, I definately think we should go down this road.
>
>>As I understand it we would need stuff like:
>>
>> WriteableXMLDBSourceImpl, WriteableFileSourceImpl etc.
>>
>>Or use/extend Vadim's XMLDBTransformer?
>>
>
>I'm afraid of having a bunch of different transformers that react on
>different namespaces just because the storage location is different.
>
>I think that a writable resource would make perfect sense.
>
Cool ! I've had this on my todo list for a while now, and I think it's
time to do it now :)
I'll start with a WriteableURLSource, so that we can play with it before
going further on more complicated implementations.
But as I'm on ski holidays this week, my work will be related to weather
conditions ;)
>>>Question #2: do you check if the <xfwt:write> element includes *one* and
>>>only *one* nested element? If not, we could end up with problems later
>>>on.
>>>
>>No I don't, I'll add that to my list, thanks.
>>
>
>'welcome.
>
>>Two other issues ....
>>
>>I need to make sure the Transformer does not emit more than one 'copy' of
>>each namespace prefix, currently multiple sources (FileGenerator &
>>XInclude) with multiple copies of the same namespace, cause multiple
>>identical xmlns attributes in the Serialized file, causing subsequent
>>Parser errors when it is read.
>>
>>A namespace declaration for xfwt is always output to the files it writes to.
>>It was already in the Document that the file is generated from so it
>>happens automatically.
>>
>>I am trying to decide if this is a good thing or not.
>>
>>In one way it is quite cute ;) a kind of signature, but in another sense it
>>is pollution, if there are no xfwt tags in the file, why the hell should it
>>declare that namespace?
>>
>>If I filter it out however, then no-one can edit files containing that
>>namespace anymore.
>>
>
>Congratulations: you win the price of 'first man on cocoon-dev to crush
>into the wall of meta-namespacing' :)
>
>Really: this is a *very* big issue and it is somewhat similar to way
>XSLT is capable of performing namespace virtualization in order to allow
>stylesheets to work on stylesheets.
>
>But this is a *very* complex thing and always smelled like FS to me.
>
>I would personally filter out all the content of the 'xfwt' namespace
>before saving and in case people has to write content that includes a
>'turned-off' 'xfwt' content (say, an XML document that explains the
>'xfwt' markup), that could be written in CDATA sections.
>
>
>>Which is the right way to go do you think?
>>
>
>I would filter them out before saving and forget about it.
>
Namespace issues that appear when extracting parts of a SAX stream are a
real PITA. I personnaly use two utilities to make life easier :
The first one is org.xml.sax.helpers.NamespaceSupport. It helps tracking
namespaces declarations so you can know all active namespaces that
should be declared a the beginning of a document extracted from a SAX
stream.
The second one is an XMLPipe of mine called "NamespaceNormalizer" : it
moves the declaration of all namespaces *used* (not only declared) in a
document at the top of this document. This is really useful to reduce
the size and increase readability of some xsl-produced documents. It's
not in the CVS now, but I can add it if people think it is usefull.
Sylvain
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: FileWritingTransformer
Posted by Michael Hartle <mh...@hartle-klug.com>.
Bert Van Kets wrote:
> I can't get the FileWriterTransformer to work in Win2K. Cocoon is
> giving me an Internal Server Error: _Could not read resource
> file:/C:/tomcat/webapps/cocoon/mount/editor/docs/test1.xml
> <file://C:%5Ctomcat%5Cwebapps%5Ccocoon%5Cmount%5Ceditor%5Cdocs%5Ctest1.xml>_.
The amount of slashes (file:/ vs. file://) might be of relevance; have
you tried something like file://... ?
Best regards,
Michael Hartle,
Hartle & Klug GbR
Re: FileWritingTransformer
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 12:12 pm +0100 18/2/02, Stefano Mazzocchi wrote:
>Jeremy Quinn wrote:
>> Whatever generates the 'child' document (the part of the 'parent' document
>> that gets written out) will issue the appropriate StartPrefixMapping calls
>> for that Fragment, no?
>>
>> Therefore it is the responsibility of the generator (Stream, Request,
>> XInclude, XSLT etc.) to output appropriate NameSpaces for the 'child', it
>> is not the 'parent's responsibility.
>>
>> I had though that StartPrefixMapping calls are only made at the beginning
>> of the Stream, when I set up a few log transformers in the sitemap, it
>> became a bit clearer.
>>
>> Is this making sense to anyone? ;)
>
>Sounds reasonable to me.
It worked like a charm ;)
I have _just_ got a page editor working ;)
I will commit it asap.
edit/ - choose a file from your docs directory to edit
edit/new - open a form to make a new page from a template
edit/get/filename.xml - open a form to edit an existing file
edit/put/filename.xml - save the file you just edited
The editor sitemap is designed to be dropped into an existing project.
You add the 'editor.xmap', the 'editor' folder to your project's sitemap
folder.
Add a mount point to your 'sitemap.xmap'.
Edit the XSL templates in the 'editor/stylesheets' folder to be able to
handle the structure of the documents you want to edit.
I am currently using the StreamGenerator to Parse the incoming edited XML,
this means that you can only edit the file as a whole document (unpleasant
at the best of times ;).
If you wanted to break a page down into several form fields, some of which
were allowed to have XML in them, currently you would have to write your
own Generator in XSP.
I am planning a RequestParsingGenerator that would handle this automatically.
Did anyone run any of the tests.
I got one report they are not working .....
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: FileWritingTransformer
Posted by Stefano Mazzocchi <st...@apache.org>.
Jeremy Quinn wrote:
> >I would filter them out before saving and forget about it.
>
> I think there could be a simple solution .....
>
> At the moment, I cache StartPrefixMapping calls from the 'parent' document,
> so I can send them to the 'child' document when it starts up.
>
> I think this is my mistake ....
>
> Whatever generates the 'child' document (the part of the 'parent' document
> that gets written out) will issue the appropriate StartPrefixMapping calls
> for that Fragment, no?
>
> Therefore it is the responsibility of the generator (Stream, Request,
> XInclude, XSLT etc.) to output appropriate NameSpaces for the 'child', it
> is not the 'parent's responsibility.
>
> I had though that StartPrefixMapping calls are only made at the beginning
> of the Stream, when I set up a few log transformers in the sitemap, it
> became a bit clearer.
>
> Is this making sense to anyone? ;)
Sounds reasonable to me.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: FileWritingTransformer
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 11:53 pm +0100 15/2/02, Stefano Mazzocchi wrote:
>Jeremy Quinn wrote:
<snip/>
>> Two other issues ....
>>
>> I need to make sure the Transformer does not emit more than one 'copy' of
>> each namespace prefix, currently multiple sources (FileGenerator &
>> XInclude) with multiple copies of the same namespace, cause multiple
>> identical xmlns attributes in the Serialized file, causing subsequent
>> Parser errors when it is read.
>>
>> A namespace declaration for xfwt is always output to the files it writes to.
>> It was already in the Document that the file is generated from so it
>> happens automatically.
>>
>> I am trying to decide if this is a good thing or not.
>>
>> In one way it is quite cute ;) a kind of signature, but in another sense it
>> is pollution, if there are no xfwt tags in the file, why the hell should it
>> declare that namespace?
>>
>> If I filter it out however, then no-one can edit files containing that
>> namespace anymore.
>
>Congratulations: you win the price of 'first man on cocoon-dev to crush
>into the wall of meta-namespacing' :)
>
>Really: this is a *very* big issue and it is somewhat similar to way
>XSLT is capable of performing namespace virtualization in order to allow
>stylesheets to work on stylesheets.
>
>But this is a *very* complex thing and always smelled like FS to me.
>
>I would personally filter out all the content of the 'xfwt' namespace
>before saving and in case people has to write content that includes a
>'turned-off' 'xfwt' content (say, an XML document that explains the
>'xfwt' markup), that could be written in CDATA sections.
>
>> Which is the right way to go do you think?
>
>I would filter them out before saving and forget about it.
I think there could be a simple solution .....
At the moment, I cache StartPrefixMapping calls from the 'parent' document,
so I can send them to the 'child' document when it starts up.
I think this is my mistake ....
Whatever generates the 'child' document (the part of the 'parent' document
that gets written out) will issue the appropriate StartPrefixMapping calls
for that Fragment, no?
Therefore it is the responsibility of the generator (Stream, Request,
XInclude, XSLT etc.) to output appropriate NameSpaces for the 'child', it
is not the 'parent's responsibility.
I had though that StartPrefixMapping calls are only made at the beginning
of the Stream, when I set up a few log transformers in the sitemap, it
became a bit clearer.
Is this making sense to anyone? ;)
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: FileWritingTransformer
Posted by Stefano Mazzocchi <st...@apache.org>.
Jeremy Quinn wrote:
> >Question 1#: how hard would it be do to
> >
> > <xfwt:write src="xmldb://localhost/result.xml">
> > <page>
> > ...
> > </page>
> > </xfwt>
>
> Currently there is a load of code in FileWritingTransformer that is File
> specific, I check for a 'file:' prefix on resolved sources.
>
> I think we would want Sylvain's WriteableSource would'nt we?
Yes, I definately think we should go down this road.
> As I understand it we would need stuff like:
>
> WriteableXMLDBSourceImpl, WriteableFileSourceImpl etc.
>
> Or use/extend Vadim's XMLDBTransformer?
I'm afraid of having a bunch of different transformers that react on
different namespaces just because the storage location is different.
I think that a writable resource would make perfect sense.
> >Question #2: do you check if the <xfwt:write> element includes *one* and
> >only *one* nested element? If not, we could end up with problems later
> >on.
>
> No I don't, I'll add that to my list, thanks.
'welcome.
> Two other issues ....
>
> I need to make sure the Transformer does not emit more than one 'copy' of
> each namespace prefix, currently multiple sources (FileGenerator &
> XInclude) with multiple copies of the same namespace, cause multiple
> identical xmlns attributes in the Serialized file, causing subsequent
> Parser errors when it is read.
>
> A namespace declaration for xfwt is always output to the files it writes to.
> It was already in the Document that the file is generated from so it
> happens automatically.
>
> I am trying to decide if this is a good thing or not.
>
> In one way it is quite cute ;) a kind of signature, but in another sense it
> is pollution, if there are no xfwt tags in the file, why the hell should it
> declare that namespace?
>
> If I filter it out however, then no-one can edit files containing that
> namespace anymore.
Congratulations: you win the price of 'first man on cocoon-dev to crush
into the wall of meta-namespacing' :)
Really: this is a *very* big issue and it is somewhat similar to way
XSLT is capable of performing namespace virtualization in order to allow
stylesheets to work on stylesheets.
But this is a *very* complex thing and always smelled like FS to me.
I would personally filter out all the content of the 'xfwt' namespace
before saving and in case people has to write content that includes a
'turned-off' 'xfwt' content (say, an XML document that explains the
'xfwt' markup), that could be written in CDATA sections.
> Which is the right way to go do you think?
I would filter them out before saving and forget about it.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: FileWritingTransformer
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 6:44 pm +0000 15/2/02, Jeremy Quinn wrote:
>At 6:24 pm +0100 15/2/02, Stefano Mazzocchi wrote:
>>Jeremy Quinn wrote:
>Currently there is a load of code in FileWritingTransformer that is File
>specific.
I just though of a potential problem with my file handling code.
Maybe someone could advise me, I am not that familiar with file
manipulation, or threading.
FileWritingTransformer opens a FileOutputStream on the File, as soon as it
receives the StartElement call with the <xfwt> tag and closes it with the
EndElement.
If there is a Parsing (or similar) error before the FileOutputStream is
closed, you loose the original file, right?
I suspect I ought to be Serialising into a temporary file and replacing the
original only after everything has worked.
I was thinking this could be an advantage because it could provide a signal
for a blocking mechanism to make sure more than one user did not attempt to
Serialise to the same file at the same time.
I could just put '.xfwt-temp' on the end of the file, and rename it after,
but I think this would be a bit untidy, I should probably make my own space
in the work directory to do this right?
How do I block the process of a second simultaneous request?
Do I 'syncronize' the temporary file?
I don't have a clue how to do this ..... help ;)
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: FileWritingTransformer
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Jeremy Quinn [mailto:jeremy@media.demon.co.uk]
>
> At 2:00 pm -0500 15/2/02, Vadim Gritsenko wrote:
> >> From: Jeremy Quinn [mailto:jeremy@media.demon.co.uk]
> >
> ><snip/>
> >
> >> >Question #2: do you check if the <xfwt:write> element includes
*one*
> >> >and
> >> >only *one* nested element? If not, we could end up with problems
> >> >later on.
> >
> >Wait, why such a limitation? What if you want to write few files, not
> >one? The result modes of the transformer might be:
> > - exception in case of error,
> > - <xfwt:result/> tag
> >
> >
> >> No I don't, I'll add that to my list, thanks.
> >
> >Please reconsider this addition :)
>
> I thought he meant something different ....
>
> ie. make sure the document you make, cannot have more than one root by
> mistake.
Oops! My bad :)
> Not, make sure there is only one <xfwt> tag in the whole stream.
>
> I'd like to be able to modify more than one file at once if required
as well.
Cool.
<snip/>
> >> Which is the right way to go do you think?
> >
> >I think there is no need (and may be even harm) to have xfwt
namespace
> >declared needlessly.
>
>
> Unless I am to buffer the whole document before Serializing it, I do
not
> understand how I can tell that the part I am Serializing to file is
going
> to have something in the xfwt namespace before I have to start prefix
> mapping.
Hm. May be then leave this namespace; better way to handle this may
arise later, after some usage of transformer.
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: FileWritingTransformer
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 2:00 pm -0500 15/2/02, Vadim Gritsenko wrote:
>> From: Jeremy Quinn [mailto:jeremy@media.demon.co.uk]
>
><snip/>
>
>> >Question #2: do you check if the <xfwt:write> element includes *one*
>and
>> >only *one* nested element? If not, we could end up with problems
>later
>> >on.
>
>Wait, why such a limitation? What if you want to write few files, not
>one? The result modes of the transformer might be:
> - exception in case of error,
> - <xfwt:result/> tag
>
>
>> No I don't, I'll add that to my list, thanks.
>
>Please reconsider this addition :)
I thought he meant something different ....
ie. make sure the document you make, cannot have more than one root by mistake.
Not, make sure there is only one <xfwt> tag in the whole stream.
I'd like to be able to modify more than one file at once if required as well.
><snip/>
>
>> A namespace declaration for xfwt is always output to the files it
>writes to.
>> It was already in the Document that the file is generated from so it
>> happens automatically.
>>
>> I am trying to decide if this is a good thing or not.
>>
>> In one way it is quite cute ;) a kind of signature, but in another
>sense it
>> is pollution, if there are no xfwt tags in the file, why the hell
>should it
>> declare that namespace?
>>
>> If I filter it out however, then no-one can edit files containing that
>> namespace anymore.
>
>Why do you think this? Just add a namespace when you need it later.
>
>
>> Which is the right way to go do you think?
>
>I think there is no need (and may be even harm) to have xfwt namespace
>declared needlessly.
Unless I am to buffer the whole document before Serializing it, I do not
understand how I can tell that the part I am Serializing to file is going
to have something in the xfwt namespace before I have to start prefix
mapping.
Maybe I do not understand Sax Processing properly.
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: FileWritingTransformer
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Jeremy Quinn [mailto:jeremy@media.demon.co.uk]
<snip/>
> >Question #2: do you check if the <xfwt:write> element includes *one*
and
> >only *one* nested element? If not, we could end up with problems
later
> >on.
Wait, why such a limitation? What if you want to write few files, not
one? The result modes of the transformer might be:
- exception in case of error,
- <xfwt:result/> tag
> No I don't, I'll add that to my list, thanks.
Please reconsider this addition :)
<snip/>
> A namespace declaration for xfwt is always output to the files it
writes to.
> It was already in the Document that the file is generated from so it
> happens automatically.
>
> I am trying to decide if this is a good thing or not.
>
> In one way it is quite cute ;) a kind of signature, but in another
sense it
> is pollution, if there are no xfwt tags in the file, why the hell
should it
> declare that namespace?
>
> If I filter it out however, then no-one can edit files containing that
> namespace anymore.
Why do you think this? Just add a namespace when you need it later.
> Which is the right way to go do you think?
I think there is no need (and may be even harm) to have xfwt namespace
declared needlessly.
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: FileWritingTransformer
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 6:24 pm +0100 15/2/02, Stefano Mazzocchi wrote:
>Jeremy Quinn wrote:
>>
>> Dear All,
>>
>> I reckon I have the FileWritingTransformer and some samples ready for
>> others to test.
>>
>> Would anyone have any objection to me adding them to the scratchpad?
>
>Absolutely not! I would use it instanstly!
Good! Thanks ;)
It is all working and ready to commit .... however, I am rusty .....
I am currently stuck trying to work out how to add to cvs :<
If you are desperate, I can email it to you off-list.
>Question 1#: how hard would it be do to
>
> <xfwt:write src="xmldb://localhost/result.xml">
> <page>
> ...
> </page>
> </xfwt>
Currently there is a load of code in FileWritingTransformer that is File
specific, I check for a 'file:' prefix on resolved sources.
I think we would want Sylvain's WriteableSource would'nt we?
As I understand it we would need stuff like:
WriteableXMLDBSourceImpl, WriteableFileSourceImpl etc.
Or use/extend Vadim's XMLDBTransformer?
>Question #2: do you check if the <xfwt:write> element includes *one* and
>only *one* nested element? If not, we could end up with problems later
>on.
No I don't, I'll add that to my list, thanks.
Two other issues ....
I need to make sure the Transformer does not emit more than one 'copy' of
each namespace prefix, currently multiple sources (FileGenerator &
XInclude) with multiple copies of the same namespace, cause multiple
identical xmlns attributes in the Serialized file, causing subsequent
Parser errors when it is read.
A namespace declaration for xfwt is always output to the files it writes to.
It was already in the Document that the file is generated from so it
happens automatically.
I am trying to decide if this is a good thing or not.
In one way it is quite cute ;) a kind of signature, but in another sense it
is pollution, if there are no xfwt tags in the file, why the hell should it
declare that namespace?
If I filter it out however, then no-one can edit files containing that
namespace anymore.
Which is the right way to go do you think?
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: FileWritingTransformer
Posted by Stefano Mazzocchi <st...@apache.org>.
Jeremy Quinn wrote:
>
> Dear All,
>
> I reckon I have the FileWritingTransformer and some samples ready for
> others to test.
>
> Would anyone have any objection to me adding them to the scratchpad?
Absolutely not! I would use it instanstly!
> I have chosen an Apache Namespace for it:
>
> xmlns:xfwt="http://apache.org/cocoon/xfwt/1.0"
>
> Is there any objection to this?
Nop
> What does it do?
> Put this in a document that gets transformed by the FileWritingTransformer:
>
> <xfwt:write src="docs/result1.xml">
> <page>
> <title>FileWritingTransformer Test Result 1</title>
> <content>
> <para>Congratulations!</para>
> </content>
> </page>
> </xfwt:write>
>
> It creates the file with the <page/> as root element.
Question 1#: how hard would it be do to
<xfwt:write src="xmldb://localhost/result.xml">
<page>
...
</page>
</xfwt>
Question #2: do you check if the <xfwt:write> element includes *one* and
only *one* nested element? If not, we could end up with problems later
on.
Anyway, sounds great.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> X-Mozilla-Status: 0009drich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: FileWritingTransformer
Posted by Stefano Mazzocchi <st...@apache.org>.
Jeremy Quinn wrote:
>
> Dear All,
>
> I reckon I have the FileWritingTransformer and some samples ready for
> others to test.
>
> Would anyone have any objection to me adding them to the scratchpad?
Absolutely not! I would use it instanstly!
> I have chosen an Apache Namespace for it:
>
> xmlns:xfwt="http://apache.org/cocoon/xfwt/1.0"
>
> Is there any objection to this?
Nop
> What does it do?
> Put this in a document that gets transformed by the FileWritingTransformer:
>
> <xfwt:write src="docs/result1.xml">
> <page>
> <title>FileWritingTransformer Test Result 1</title>
> <content>
> <para>Congratulations!</para>
> </content>
> </page>
> </xfwt:write>
>
> It creates the file with the <page/> as root element.
Question 1#: how hard would it be do to
<xfwt:write src="xmldb://localhost/result.xml">
<page>
...
</page>
</xfwt>
Question #2: do you check if the <xfwt:write> element includes *one* and
only *one* nested element? If not, we could end up with problems later
on.
Anyway, sounds great.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: FileWritingTransformer
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Jeremy Quinn [mailto:jermq@media.demon.co.uk]
>
> Dear All,
>
> I reckon I have the FileWritingTransformer and some samples ready for
> others to test.
>
> Would anyone have any objection to me adding them to the scratchpad?
>
> I have chosen an Apache Namespace for it:
>
> xmlns:xfwt="http://apache.org/cocoon/xfwt/1.0"
>
> Is there any objection to this?
Go ahead, add it.
Vadim
>
> What does it do?
> Put this in a document that gets transformed by the
FileWritingTransformer:
>
> <xfwt:write src="docs/result1.xml">
> <page>
> <title>FileWritingTransformer Test
Result 1</title>
> <content>
> <para>Congratulations!</para>
> </content>
> </page>
> </xfwt:write>
>
>
> It creates the file with the <page/> as root element.
>
>
>
>
> --
> ___________________________________________________________________
>
> 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