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