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/22 22:00:17 UTC
FileWritingTransformer update
Dear All,
I am almost ready to commit a new version of FileWritingTransformer.
There is a new experimental/demo file-editor called <slash-edit/>.
I updated the transformer to try and stop it overwriting files when there
is an error. I now write into a temp file (which blocks) and rename it when
done.
This does not stop the problem of catching invalid XML submitted in forms
however.
I am using the StreamGenerator to capture the edited XML from a whole file.
When it's Parser finds non well formed XML, it throws a ProcessingException
and the FileWritingTransformer does not get to know anything about it.
Valid XML still gets happily written to disk, but missing everything after
the faulty tag.
The StreamGenerator could be modified, but I prefer the solution of writing
a RequestParsingGenerator, that can selectively parse any number of form
fields and won't throw ProcessorExceptions but encapsulate defective XML
fields as character data, with an error message in the Stream.
Does this make sense?
What I cannot work out is, would defective XML markup, passed down the
stream as character data, then transformed into a form to re-edit and fix,
be real tags or would they be Entities by then?
If they have been converted to Entities and you fix and re-post, they will
be written as Entities, no?
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: FileWritingTransformer update
Posted by Peter Royal <pr...@managingpartners.com>.
On Sunday 24 February 2002 05:05 am, Jeremy Quinn wrote:
> At 3:36 pm -0500 23/2/02, Peter Royal wrote:
> >On Saturday 23 February 2002 09:57 am, Jeremy Quinn wrote:
> >> One issue I KNOW exists.
> >> If you send out an HTML form, with XML tags inside a form field that
> >> resemble HTML tags (<br/>, <li></li>, etc.) then the HTMLSerializer
> >> breaks them!!!
> >
> >Use XHTML. We're sending that to both Mozilla-based browsers and IE5+
> >browsers with no problems.
>
> I tried that, but obviously did it wrong.
> How is your HTML Serializer set up?
As Vadim said, its the XML serializer..
<map:serializer name="xhtml" mime-type="text/html"
src="org.apache.cocoon.serialization.XMLSerializer" pool-max="128"
pool-min="32" pool-grow="8" logger="sitemap.core">
<doctype-public>-//W3C//DTD XHTML 1.0 Strict//EN</doctype-public>
<doctype-system>http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd</doctype-system>
<encoding>UTF-8</encoding>
</map:serializer>
-pete
--
peter royal -> proyal@managingpartners.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: FileWritingTransformer update
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 12:44 pm -0500 24/2/02, Vadim Gritsenko wrote:
>> From: Jeremy Quinn [mailto:jeremy@media.demon.co.uk]
>>
>> At 3:36 pm -0500 23/2/02, Peter Royal wrote:
>> >On Saturday 23 February 2002 09:57 am, Jeremy Quinn wrote:
>> >> One issue I KNOW exists.
>> >> If you send out an HTML form, with XML tags inside a form field
>that
>> >> resemble HTML tags (<br/>, <li></li>, etc.) then the HTMLSerializer
>breaks
>> >> them!!!
>> >
>> >Use XHTML. We're sending that to both Mozilla-based browsers and IE5+
>> >browsers with no problems.
>>
>> I tried that, but obviously did it wrong.
>> How is your HTML Serializer set up?
>
>Ahem. XHTML is XML. So I guess you need XML serializer then. Makes
>sense? :)
OK, this is what I have tried in the past. I have never got a browser to
handle it correctly.
Maybe we need to work out a compliant way to say to the HTML Serializer
"this is not HTML leave it alone!"
Can you switch the default namespace (namespace without prefix) in the
middle of a document, I believe you can ..... no?
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 update
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Jeremy Quinn [mailto:jeremy@media.demon.co.uk]
>
> At 3:36 pm -0500 23/2/02, Peter Royal wrote:
> >On Saturday 23 February 2002 09:57 am, Jeremy Quinn wrote:
> >> One issue I KNOW exists.
> >> If you send out an HTML form, with XML tags inside a form field
that
> >> resemble HTML tags (<br/>, <li></li>, etc.) then the HTMLSerializer
breaks
> >> them!!!
> >
> >Use XHTML. We're sending that to both Mozilla-based browsers and IE5+
> >browsers with no problems.
>
> I tried that, but obviously did it wrong.
> How is your HTML Serializer set up?
Ahem. XHTML is XML. So I guess you need XML serializer then. Makes
sense? :)
Regards,
Vadim
>
> 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 update
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 3:36 pm -0500 23/2/02, Peter Royal wrote:
>On Saturday 23 February 2002 09:57 am, Jeremy Quinn wrote:
>> One issue I KNOW exists.
>> If you send out an HTML form, with XML tags inside a form field that
>> resemble HTML tags (<br/>, <li></li>, etc.) then the HTMLSerializer breaks
>> them!!!
>
>Use XHTML. We're sending that to both Mozilla-based browsers and IE5+
>browsers with no problems.
I tried that, but obviously did it wrong.
How is your HTML Serializer set up?
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 update
Posted by Peter Royal <pr...@managingpartners.com>.
On Saturday 23 February 2002 09:57 am, Jeremy Quinn wrote:
> One issue I KNOW exists.
> If you send out an HTML form, with XML tags inside a form field that
> resemble HTML tags (<br/>, <li></li>, etc.) then the HTMLSerializer breaks
> them!!!
Use XHTML. We're sending that to both Mozilla-based browsers and IE5+
browsers with no problems.
-pete
--
peter royal -> proyal@managingpartners.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: FileWritingTransformer update
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 11:27 am +0100 23/2/02, Stefano Mazzocchi wrote:
>Jeremy Quinn wrote:
>>
>> Dear All,
>>
>> I am almost ready to commit a new version of FileWritingTransformer.
>>
>> There is a new experimental/demo file-editor called <slash-edit/>.
>
>upload upload upload :)
It's done, I was not subscribed to cvs list with my Apache account, so the
commit mails were getting bounced.
>
>> I updated the transformer to try and stop it overwriting files when there
>> is an error. I now write into a temp file (which blocks) and rename it when
>> done.
>
>Yes, that's the good approach.
And now Sylvain has implemented that approach in the FileSource.
It would still be nice to implement 'waiting' because the file is never
likely to be held up for long, and it is much more inconvenient rejecting
posts, than waiting an extra couple of seconds.
>
>Question, do you handle collisions? I mean: what if two people write two
>temp files at the same time? did you add timestamping to the temp-name?
We are just sticking '.tmp' on the end of the filename.
Then use File.createNewFile(File) to make the temp file, it fails if there
is one there already and the operation is atomic.
>> RequestParsingGenerator, that can selectively parse any number of form
>> fields and won't throw ProcessorExceptions but encapsulate defective XML
>> fields as character data, with an error message in the Stream.
>>
>> Does this make sense?
>
>Yes, it does.
Cool, thanks.
>Also, I've been experimenting with XML creation on the client side using
>javascript and even if it's not difficult at all (XML can be very easy
>stuff sometimes!), I think it's better not to expect things from the
>client but do them on the server as much as possible.
These might make useful libraries for other people.
>> What I cannot work out is, would defective XML markup, passed down the
>> stream as character data, then transformed into a form to re-edit and fix,
>> be real tags or would they be Entities by then?
>
>Gosh, Jeremy, why do you always ask these difficult questions that I
>can't find answers myself :-D
I'll take that as a compliment ;)
>No, seriously, I think you've crashed into another big wall: XML
>roundtripping.
That's the one.
>This is a *big* issue.
I know, it's a *******!
One issue I KNOW exists.
If you send out an HTML form, with XML tags inside a form field that
resemble HTML tags (<br/>, <li></li>, etc.) then the HTMLSerializer breaks
them!!!
We really are going to have to do something about this, if editing XML in
HTML Forms is ever going to be a reality with Cocoon.
>For example, what if the client editor was not form-based? we need some
>more abstraction on this concept, I guess... but anyway, for now, just
>something that works is ok, we'll proceed incrementally.
Incrementally, yes, we do not seem to be able to predict all the subtle
effects in advance. For instance it took me over a day to work out how the
hell to get XSLT to output an xmlns attribute in the right place, so it was
actually inside the form field when it was sent back to the StreamGenerator
(which would otherwise freak out).
Thanks for the great 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: FileWritingTransformer update
Posted by Robert Koberg <ro...@koberg.com>.
----- Original Message -----
From: "Stefano Mazzocchi" <st...@apache.org>
>
> > What I cannot work out is, would defective XML markup, passed down the
> > stream as character data, then transformed into a form to re-edit and
fix,
> > be real tags or would they be Entities by then?
>
> Gosh, Jeremy, why do you always ask these difficult questions that I
> can't find answers myself :-D
>
> No, seriously, I think you've crashed into another big wall: XML
> roundtripping.
>
> This is a *big* issue.
>
> For example, what if the client editor was not form-based? we need some
> more abstraction on this concept, I guess... but anyway, for now, just
> something that works is ok, we'll proceed incrementally.
>
You might want to check out Macromedia's Dreamweaver and it's extensibility
mechannism. This might give you some ideas. Dreamweaver is basically written
in JavaScript (so it's oPEN :).
best,
-Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: FileWritingTransformer update
Posted by Stefano Mazzocchi <st...@apache.org>.
Jeremy Quinn wrote:
>
> Dear All,
>
> I am almost ready to commit a new version of FileWritingTransformer.
>
> There is a new experimental/demo file-editor called <slash-edit/>.
upload upload upload :)
> I updated the transformer to try and stop it overwriting files when there
> is an error. I now write into a temp file (which blocks) and rename it when
> done.
Yes, that's the good approach.
Question, do you handle collisions? I mean: what if two people write two
temp files at the same time? did you add timestamping to the temp-name?
> This does not stop the problem of catching invalid XML submitted in forms
> however.
>
> I am using the StreamGenerator to capture the edited XML from a whole file.
> When it's Parser finds non well formed XML, it throws a ProcessingException
> and the FileWritingTransformer does not get to know anything about it.
> Valid XML still gets happily written to disk, but missing everything after
> the faulty tag.
>
> The StreamGenerator could be modified, but I prefer the solution of writing
> a RequestParsingGenerator, that can selectively parse any number of form
> fields and won't throw ProcessorExceptions but encapsulate defective XML
> fields as character data, with an error message in the Stream.
>
> Does this make sense?
Yes, it does.
Also, I've been experimenting with XML creation on the client side using
javascript and even if it's not difficult at all (XML can be very easy
stuff sometimes!), I think it's better not to expect things from the
client but do them on the server as much as possible.
> What I cannot work out is, would defective XML markup, passed down the
> stream as character data, then transformed into a form to re-edit and fix,
> be real tags or would they be Entities by then?
Gosh, Jeremy, why do you always ask these difficult questions that I
can't find answers myself :-D
No, seriously, I think you've crashed into another big wall: XML
roundtripping.
This is a *big* issue.
For example, what if the client editor was not form-based? we need some
more abstraction on this concept, I guess... but anyway, for now, just
something that works is ok, we'll proceed incrementally.
--
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