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
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
