Excuse me while I re-start this thread, was [Re: [RT] Protocol based
sources eliminates almost every generator[was Re: Showstoppers for 2.0
final was RE: [tale+rant] The 2.0 syndromeand
 [Vote]: Final Release Date]]



At 8:30 pm +0100 27/11/01, Stefano Mazzocchi wrote:
>Jeremy Quinn wrote:
>>
>> At 3:51 pm +0100 26/11/01, Giacomo Pati wrote:
>> >Quoting Berin Loritsch <[EMAIL PROTECTED]>:
>> >
>> >> Ugo Cei wrote:
>> >>
>> >> > Giacomo Pati wrote:
>> >> >
>>
>> >> > - write a Source (this I hadn't even figured until I read Giacomo's
>> >> >   mail)
>> >
>> >This is nothing I thought of doing.
>>
>> This is something I have been discussing with Sylvain and others.
>>
>> I have been trying to write an RT about it .......

[snip]

>> The idea is to provide similar functionality to the old FP Cocoon 1 TagLib,
>> but (this time) to disassociate the XML manipulation from the source or
>> destination, so that the modified XML could be written to file, sent to
>> SQL, Castor, stored temporarily in the user's session, whatever.
>
>I'm happy you bring this on the table because I was thinking about the
>best way to make this client-side editor connect with a solid
>repository.
>
>But I don't think I understood your diagram above :)
>
>Can you restate?

Yes, thanks for your reply.

I had previously been thinking of this in terms of TagLibs. After writing
the above (and sorry about the diagram, my mailer "collapsed" it ;) I found
the beginning of your thread "sharing microsoft experience" (I missed that
message originally).

You wrote:
>So, here's the idea:
>
> 1) Connect the inline-editor with a few lines of javascript that copy
>the nodes included in the editing section (normally a DIV with special
>ID) in the FORM body,
>
> 2) Connect some botton on the screen to the POST action of the form
> 3) direct the action to Cocoon,
> 4) use the StreamGenerator
> 5) transform the semantic XHTML to your semantic markup
> 6) write a transformer to save it into your favorite CMS
> 7) style the resulting information
> 8) send it back to the client

So this made me think about the same issue in terms of transformers.

I have tried to turn the above into a pseudo sitemap snippet:

                StreamGenerator - picks up xml field, for a form with one xml blob
                        -=- or -=-
                RequestGenerator - if you have individual fields to be made into xml

                ActionSet - Authorise the user, [lock the Source], Validate input
                        XSLT - set up SourceReadingTransformer tags,
                                         - Source ref from SiteMap; Request, Session, 
Action etc.
                                         - eg. context://, file://, xmldb://
                                            maybe even: resource://, sql://, ldap://, 
castor://, jaxb://,
ftp:// (??)
                        SourceReadingTransformer (also known as XInclude!)
                                         - reads in Source
                                         - reads in user response template
                                         - reads in new element template etc
                        XSLT - transform Source, updating it with the new content
                                         - the sitemap has chosen a specific 
stylesheet for the
                                            transformation required (add, edit, 
rename, delete, move etc)
                        SourceWritingTransformer
                                         - Sources need to implement WritableSource
                                         - eg. context://, file://, xmldb://, etc.
                        [Action - release Source] - may be part of WritableSource's 
behavior
                        XSLT - apply style to user response
                        Serialise
                [Action - release Source] - may be part of WritableSource's behavior
                XSLT - apply style to error response
                Serialise

This snippet raises two issues (to me anyway):

        1. it introduces the concept of a "WritableSource", ie. a Source that can
be read from and written to.
                obvious candidates are the pseudo protocols: context://, file://, 
xmldb://.
                Should include the ability to temporarily "lock" the Source.

                we currently rely on ad hoc solutions for this, we have no general way 
of
                modifying existing content, unless it is stored in SQL
                not everyone wants to work in SQL (as the popularity of FP showed us)

        2. When existing XML fragments (from whatever Source) need to be modified
by incoming data
                do we :

                i. provide a specific language for the manipulation (ie. XUpdate)
                ii. rely on using a general purpose language for the transformation
like XSLT

                I err on the side of XSLT now ...... XUpdate is not a W3 standard, it's
implementation
                in terms of the lexus project appears to be obsolete

The main issue here though is "WritableSource". Is this the way to go?

As we have the growing perception for the need for CMS etc., but no way to
generically write to a Source, each person's solution has to be hand coded,
and is often therefore not portable or reusable.

I feel we should avoid the position we got into in Cocoon 1, where each
technique for modifying existing content, was specific to the storage
medium of the content.


I hope this make a bit more sense now .......


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]

Reply via email to