Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Date: Wed, 5 Dec 2001 09:32:27 -0500
From: Tim Myers <phantom@stserv.hcf.jhu.edu>
To: cocoon-dev@xml.apache.org, haul@informatik.tu-darmstadt.de
Subject: Re: Config files: where?
Message-ID: <20011205093227.A20544@stserv.hcf.jhu.edu>
References: <20011204124128.A18165@stserv.hcf.jhu.edu>
 <20011205110546.J28035@bremen.dvs1.informatik.tu-darmstadt.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20011205110546.J28035@bremen.dvs1.informatik.tu-darmstadt.de>;
 from haul@dvs1.informatik.tu-darmstadt.de on Wed, Dec 05,
 2001 at 11:05:46AM +0100

Christian wrote:
> As this whole mod-db stuff is currently more a proposal than set in
> stone I'd like to hear your comments on it. Esp. where you'd like to
> have the helpers (from .../ModularDatabaseAccess/*) should be
> declared. I'm still undecided whether this should be done in a sitemap
> or in cocoon.xconf.
You declare the database connection driver(s) in web.xml.
The connections themselves are declared in cocoon.xconf.
Right now you are putting the helper classes right in the configuration file.  That is fine from a programmers point of view... but you are right and make it clear that that is not the right approach.

It comes down to who's concern is the sitemap... who's is cocoon.xconf.
cocoon.xconf is very much a sys-admin's tool, like web.xml.

sitemap.xmap might be too, but i see some pointy-hairs wanting to play with it at some point.  In the exception discussion they are having right now they talked about stuffing error matchers into the sitemap and naming exception classes in the sitemap.  Out of that someone said there shouldn't be java classnames in the sitemap, only symbolic references to them.  The helper classes themselves, even when written by users, all have to be installed in the lib or class directory of the webapp, so they are sys-admin type concerns anyway.

Right now, all action classes are declared in the sitemap.  If it is the same person editing the sitemap, administering cocoon, and writing some code (which it would be during evaluation phase but probably not afterwards) then layers of abstraction are more of an impediment than asset.  As the group using cocoon within an organization gets larger, it is valuable to have a visual editor which is simple enough for all of those managers whose favorite two programs are visio and powerpoint.  How much simpler is it really to have <action type="updateDB"  then to have org.apache.cocoon.action.DBUpdateAction?

As long as there is a way to communicate the big picture among a group who is sharingadministration of cocoon, all class names should come out of sitemap.xmap.  So i would reluctantly say that cocoon.xconf is a better place to declare the helper classes.  They aren't even used in the sitemap for the most part anyway.  They are used in the configuration files(which are beginning to look just a little bit like a flow map).

Tim


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