Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3E646210.6000905@apache.org>
Date: Tue, 04 Mar 2003 09:21:36 +0100
From: Stefano Mazzocchi <stefano@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.3b) Gecko/20030202
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: Flow + XForms + Beans + Databases
References: <35471.10.0.0.1.1046756694.squirrel@ags01.agsoftware.dnsalias.com>
In-Reply-To: 
 <35471.10.0.0.1.1046756694.squirrel@ags01.agsoftware.dnsalias.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Antonio Gallardo wrote:

> 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                               <stefano@apache.org>
    Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------