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: map:parameter in map:components
Date Mon, 23 Jul 2001 16:24:32 GMT
On 20.Jul.2001 -- 11:43 PM, giacomo wrote:
> On Fri, 20 Jul 2001, Christian Haul wrote:
> > OK, what about ComposerAction then. Almost all subclasses have
> > parameters specified in sitemap. Although few use the configure
> > feature. I volunteer to extend them to use it. Afterall, a more
> > consistent behaviour would be exposed to the user.
> 
> A ComposerAction is one that gets a ComponentManager because it uses
> components to get its jobe done. I think what you want is a
> ConfigurableAction that has an additional configure method implemented.

OK, I created a AbstractConfigurableAction and a
ConfigurableComposerAction inheriting the method from the former. Code
from ComposerAction is copied (few lines only, damn it, no multiple
inheritance in java :(

Since AbstractAction implements Configurable this is somewhat strange,
I think.

I've moved some actions and modified those that didn't take default
parameters before to adhere to this model.

> But most of the time this doesn't make sense as it needs to be
> overridden anyway because of the fact that each components uses it's own
> configuration. If you find that a group of Actions have the same type of
> configuration, then ok, build up an abstract class for them (or build
> up a common configure() method for them if they're already based on a
> common super class).

>From those that use configuration, 100% use this key-value scheme.

> No, simply clean the configure method as it was before.

Done.

> > And while we're at it: I'd like to make this "reloadable descriptor"
> > feature used by descendants of AbstractComplimentaryConfigurableAction
> > configurable site wide from cocoon.xconf. How would that be done?
> 
> Hm.., I've never use the AbstractComplimentaryConfigurableAction so I
> can't answer this.

Let me rephrase it: How is anything made configurable from
cocoon.xconf that is just a setting "true"/"false" and no component?
(I fear it isn't.)

> > And another one: If an action would be composed of some components, is
> > there a class around that does the composition? I've currently copied
> > relevant bits from AbstractSitemap. The way outlined in the new
> > developing with Avalon paper seems not to work since it would need an
> > extra config file and not just some Configuration.
> 
> Don't get this. We almost put every service/logic we need in an c2 app
> into it as an Avalon component. So most of our Actions do their work by
> using other components. I don't know what the problem is you are
> facing.

But at least sitemap does not use a builder but sets up everything
itself. I think because it doesn't use a file that is solely
configuration. I'd like to use a similar scheme for an action that is
composed of different components. So I thought there might be
something that does this already.

> > And a last one: I proposed some changes to esql.xsl on 04.jul. and
> > posted a patch on 11.jul. You asked me not to commit changes to
> > esql.xsl without review. So far no one had any comments. What course
> > of action would you suggest?
> 
> I say if no one responded/reviewed your suggestion within a week put it
> into CVS if you think you can take the responsability for the change.

OK, will do. I figure I should check it into C2.1 first to get a bit
less flamed :-)

	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