cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: data goes in, data goes out
Date Thu, 29 Nov 2001 15:07:10 GMT
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.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message