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: Chaining order (Re: [VOTE] Input module chaining)
Date Tue, 08 Oct 2002 15:59:53 GMT
On 08.Oct.2002 -- 04:38 PM, Carsten Ziegeler wrote:
> Piroumian Konstantin wrote:
> > Configuration of input modules is a little different matter. If you have
> > good suggestions on how to configure them in the sitemap then nobody will
> > have objections, I think. What we couldn't agree on all this time was the
> > modularity and module chaining implementation. Jeff, Chris, am I wrong?
> >
> Ok, let's try this: I made a suggestion for a simple InputModule interface
> today - nobody really complained about it - so this should be the way to go,
> right?

Well ... ;-) Enumeration to Iterator is fine.

> Now, it seems that you all have come to a conclusion for chaining etc. Just
> post an interface/description for this and we can agree on it or change it
> until we all are happy.

As already said, chaining does not require a change to the interface.

Configuration.

Basically, one should setup everything on instantiation. This requires
doing it in cocoon.xconf. 

This is not really nice, but AFAIU having different configurations for
application parts is not coming before we have blocks. We had lots of
discussions to enable this in sitemap -- agreeing not to do it.

The easiest way would be to introduce new components in sitemap. But
if you don't know what implementation lives behind an InputModule
name, it does not make sense to configure it.

So, we have no real alternative.

Regarding SoC: The *real* idea is not to ever use e.g. "request-param"
but to use your own instance. Change the component, the application
doesn't need to know.

Run-time configuration.

Remember, this should be used in complex scenarios. Database mapping
files for example. You can do it there, there's room for it. Other
scenarios will have their own configuration / descriptor files. Do it
there. That's why there is a means to pass run-time configuration.

Why would you want to do complex configuration changes in sitemap? To
change the way data is inserted in a database? SoC?

Please keep in mind that the use of InputModules in sitemap is sexy
but it is only a small by-product of the real thing.

LifeCycle, yes. To me it appears to costly. I want to pass additional
information to the modules -- for one call only. And I don't want to
encode them in a URL.  Passing a configuration -- or parameters for
that matter -- as Avalon Configuration looked right to me. Especially,
when this is located in a descriptor file.

	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