On Wed, 28 Nov 2001, Jeremy Quinn wrote: > > 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
Jeremy, you missed the point that Actions are executed immediately when selected by the sitemap engine whereas pipeline component are executed after collecting all of them to assemble a pipeline. Thus your sitemap snippet above won't work as expected. Your [Action - release Source] would be executed BEFORE the SourceWritingTransformer ever had a chance to write. You have to take into account that we have two different groups of components in the sitemap. An immediate executed group (Actions, Matchers, and Selectors) and those getting collected and assebled to form a pipeline (Readers, Generators, Transformers, and Selectors). > > 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. Prowler? > 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 > Giacomo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
