(comment inline:) > -----Original Message----- > From: Jeremy Quinn [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, 28 November 2001 9:58 am > To: [EMAIL PROTECTED] > Subject: WritableSource > > > > 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)
Could we use a version control software (CVS/VSS...)? > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
