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
<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]
