cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Haul <h...@dvs1.informatik.tu-darmstadt.de>
Subject Re: [RT]: InputModules interfaces
Date Mon, 07 Oct 2002 16:34:12 GMT
On 07.Oct.2002 -- 05:51 PM, Sylvain Wallez wrote:
> Christian Haul wrote:
> 
> >On 07.Oct.2002 -- 04:50 PM, Carsten Ziegeler wrote:

> >>>>c) What this optional "modeConf" Parameter?
> >This feature is not used with respect to the sitemap usage.
> >
> >It allows to pass arbitrary configuration data to a module. This could be 
> >a output format, details about the data source or whatever. The 
> >DigestMetaModule for example can be told what algorithm to use, what salt 
> >to use, and whether the result should be encoded as a string. Basically, 
> >the same information that can be passed upon configuration can be passed 
> >at run-time.
> >
> >Therefore, they throw configurationExceptions. I believe, none actually 
> >does.
> 
> Is it good to allow passing a configuration at request-time ? This seems 
> like FS to me (Carsten, it's my turn, now ;-)

Sort of ;-) I believe the only real uses I have with this one are
a) map parameters to different names
b) switch the underlying module to another one in case of meta modules

> Also, this can hurt performance : extracting configuration data is 
> expensive. And where does this request-time configuration come from ? Is 
> it built from scratch by objects using the module ? This again can hurt 
> perfs.

The origin of all this is the rewrite of the database actions. They
use a descriptor file for the database structure that is now augmented
with information where to get the data from. Thus this configuration
data is cached by the database action and passed to the module as
needed.

A frequently needed issue is the part were the database action assumes
a name for a parameter but that does not match the application
(e.g. it is the result of an insert operation and thus carries the
name of _that_ table.attribute).

> If several different configuration are needed by a module, doesn't this 
> mean in fact that there should be several instances of the module with 
> different configurations declared in cocoon.xconf ?

I guess apart from the mapping issue which can be solved differently,
yes.

	Chris.
-- 
C h r i s t i a n       H a u l
haul@informatik.tu-darmstadt.de
    fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

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


Mime
View raw message