On the other hand the Database API can be usefull to get some stuff directly form the Database.
It's a shortcut and it's simply too easy. "too easy" around Cocoon, normally means "too easy to abuse".
What is abuse? is when you hit a wall right after you went in production and all the time you saved, you end up spending it later and your development capabilities don't scale.
Why? very simple: having SQL into the flow mixes concerns!!! and we have designed cocoon to reduce concern overlap to the bare minimum required by the complexity of the problem to solve.
In this case, it's the opposite: we are mixing concerns so that the same person can do an easier job at connecting to its database.
This is PHP-like, people. The PHP world has shown pretty evidently that this doesn't scale along with the complexity of the web application.
If we start introducing under-designed complexity shortcuts in such a critical piece of the framework, we undermine our capabilities to stand the pressure of massive web needs.
Database connectivity is simply too important to do it without a complete concern analysis and without a collaborative discussion.
The real value of Chris' contribution in this case is to have shown us how easy it is to abuse the flow framework and now 'elegant and clean' solutions that mix concerns can appear.
But this should help us collectively raise the sensibility of our FS alarms, not to lower them!
If managing the sitemaps semantics was hard, managing the Flow Object Model will be even worse.
So, be prepared.
-- Stefano Mazzocchi <[EMAIL PROTECTED]> Pluralitas non est ponenda sine necessitate [William of Ockham] --------------------------------------------------------------------
