cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <je...@media.demon.co.uk>
Subject Re: XSP problem
Date Tue, 23 May 2000 12:58:41 GMT
On 23/5/00 at 9:55 am, ulim@denic.de (Ulrich Mayring) wrote:

>Donald Ball wrote:
>> 
>> Hmm. Logically speaking, your idea makes perfect sense, though I wonder
>> how efficient an XML file editor that worked like this would be... don't
>
>I think for applications, where you read the document 9 times and write
>it only one time, it would be sufficient. The Xerces serializers, that
>XMLForm uses, are also very sluggish when saving data.
>
>> care too much, myself, i'm more interested in working code than efficient
>> code. I wonder how this would tie into Jeremy's form taglib stuff...
>
>I didn't know Jeremy was onto that. But I always suspected he rules :)

I suspect not :) I am largly in the dark about how to actually implement this stuff, it's
all I can manage at the moment to try and work out what it should be.

>But strictly speaking Forms and Include/Outclude are two different
>things. Forms provide a GUI for dealing with XML data - and there are
>many important things that a Form taglib could do. However, I think it
>should not read and write XML data, just as I/O should not model a user
>interface.
>
>Very frequently you need I/O without forms - any place where you've been
>using <util:include-uri> or <util:include-file>.
>
>And also very frequently you need forms without I/O (e.g. database query
>forms).

+1

A Form TagLib would need to serialise modified Document objects to XML files on disk, the
same as other applications and TagLibs. It makes sense to seperate out this functionality
rater than incorporate it into the Form TagLib as would have been the case.

A Form TagLib would want to make use of a wide range of I/O TagLibs to read and write data;
SQL, File, EMail, LDAP, FTP?, XML/RPC?, RMI?; the author would just use the one that makes
the connection they want to make.

The difference between using an XInclude TagLib and the util:include... TagLib is that XInclude
supports including document fragments using XPointer, it that correct? Are there other differences?

Would it make more sense to add write functionality to to the XInclude TagLib, muddying the
waters?

Or would it be better to start again with a full read/write XPointer savvy FileTagLib in parallel
to the read/write functionality in the SQLTagLib?

Or write a FileWriteWithXPointer/util:save TagLib to complement XInclude/util:include?

How important is the ability to read and write document fragments using XPointer in a Form
Handling TagLib? 

This ability won't be available from a Form TagLib for users of SQL (etc.) I/O will it?

I think the Form TagLib would need it's own way of defining how to modify a fragment in an
existing document/query. I don't see that getting the whole document to work with instead
of a fragment using XPointer makes much difference, all the data still has to be parsed. No?



reagrds Jeremy

      ____________________________________________________________________

      Jeremy Quinn                                             media.demon
                                                           webSpace Design
     <mailto:jeremy@media.demon.co.uk>       <http://www.media.demon.co.uk>
      <phone:+44.[0].20.7737.6831>          <pager:jermq@sms.genie.co.uk>



Mime
View raw message