Jeremy Quinn wrote (double quotes mean my words):
> >So, I think I just proved that the current pipeline architecture is
> >*not* inherently biased toward outward data flow, despite the component
> >names that seem to inspire the opposite.
>
> excellent analysis
thanks.
> >Thus, a "store" is behaviorally equivalent to a "transformer".
>
> I agree. It is like fitting a 'Tee' junction.
Exactly. Specific internal behavior depends on implementations, but the
architecture is general enough to take care of this case also.
> >As Jeremy pointed out, XUpdate is a choice. I must tell you that I don't
> >like XUpdate that much, but I admit it's a choice.
>
> I am in two minds about an XUpdate Transformer per se.
> The 'standard' is not a Standard, the draft is incomplete.
Well, XSP is no more 'standard' than this and probably incomplete as
well. These points are not the problem.
> The job of modifying a fragment of XML (from file, xmldb etc.) is easily
> achievable with purpose built XSLT stylesheets, so a Transformer that
> specifically handles the XUpdate namespace while it might be useful for
> people who are not so happy with XSLT, is not actually required for the job.
ok.
> What is actually missing (as you have stated) is the ability to write to
> datasources in a standard way (set up from the sitemap).
Yep.
> Once that is in place, adding an XUpdate Transformer to the mix merely
> provides an alternative to writing your own XSLT to make the transformation.
Good point.
> Incedentally, I spent some time yesterday trying to work out if standard
> XUpdate transformation could be handled by an XSLT Stylesheet rather than
> written in Java. I suspect it would be extremely difficult, if not
> impossible. XSLT is not good at selecting, using dynamic XPaths (am I
> right?).
hmmm, from a theorical perspective, if XUpdate cannot be easily
transformed into a stylesheet, then it means they are sufficiently
different to make XUpdate existance more interesting. Wouldn't you
agree?
> >Jeremy named it "WritableSource" (which is admittedly an ossimoron).
>
> I did not come up with the name, I will withhold the name of the author to
> avoid further embarrassment ;)
Let me guess: Sylvain? :)
Ah, c'mon guys, this is no critique, even a poor name can sparkle a
discussion that creates outstanding results. So, please, no need to feel
embarassment of any kind when discussing architectures.
> >Berin proposed to look at Monitors (which is not exactly a name that
> >reminds me of a storage location, BTW)
> >
> >Anyway, this is, at this point, more an Avalon discussion than a Cocoon
> >one, since this is a general thing.
>
> I think the Monitor package provides a JavaBean-type callback mechanism to
> be notified of asset changes, this will be useful for cache control, no?
Absolutely.
> >As for helping Jeremy to implement a Cocoon 2.0 version of FP, my
> >suggestion would be to aim at creating a general XUpdateTransformer that
> >wraps round the existing DB:XML API to make code persistent in a native
> >XML DB solution.
>
> It is not a 'version' of FP I'd like to produce (FP taglib was horrid!),
> but a way to re-create the same functionality in a non datasource-dependant
> way.
Ok, great. (I found FP horrid as well, but it didn't matter because it
was the functionality that was missing and sometimes worse is better) [I
said "sometimes"!]
> How can we do this in a way that allows people to write protocols for
> reading and writing from any datasource. While I applaud the use of XML:DB
> (it's great!) file-systems, webdav, cvs, ftp, etc etc. will also be
> relevant for others. Given the interface, I would not be surprised to see
> these contributed (we got an FTP generator recently!).
>
> For instance, imagine being able to develop a prototype CMS that stores
> content in files (for ease of development) then to be able to move the
> whole thing to XML:DB merely by changing a couple of protocol strings in
> their sitemap and importing the files into a collection. This would deeply
> rock IMHO!
Absolutely. But it's a lower priority compared to making this possible
in the first place, IMO.
> >Having the ability to go both ways from a native xml db would instantly
> >turn Cocoon into a CMS, or, at least, in a toolkit to create your
> >customized CMS (which is what I'd really like to have, rather than a
> >fixed CMS)
>
> Definately, a toolkit is the way to go!
> I have tried using other people's idea of "The Ideal CMS" it seldom is!
> I have even written several of my own, they were never ideal for anybody else.
Exactly.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
