On Fri, 20 Jul 2001, Christian Haul wrote:
> On 20.Jul.2001 -- 07:35 AM, giacomo wrote:
> > On Thu, 19 Jul 2001, Christian Haul wrote:
>
> > No, no. I don't mean is is wrong to have configured Action instead of
> > parameterized one in the pipeline. My insisting was
> >
> > 1. don't use a <parameter> element for configuration
>
> Agreed.
>
> > 2. don't have a general configure() method/names in AbstractAction.
> > Use others more suitable for this (ie. AbstractDatabaseAction)
>
> 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.
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).
>
> >
> > > Hence, I believe that all actions should be able to receive the same
> > > configuration information for sitemap wide use that they take per
> > > invokation.
> >
> > I don't get this. Do you mean we should be able to somehow say
> > <foo>bar</foo> and every single Action in the system should receive this
> > as configuration?
>
> No, only this action instance. E.g.
>
> <map:action name="form-validator1"
>src="org.apache.cocoon.acting.FormValidatorAction">
> <descriptor>context://descriptor1.xml</descriptor>
> </map:parameter>
> <map:action name="form-validator2"
>src="org.apache.cocoon.acting.FormValidatorAction">
> <descriptor>context://descriptor2.xml</descriptor>
> </map:parameter>
>
> would of course have different descriptors. But whenever
> "form-validator1" is used, it knows to use "context://descriptor1.xml"
> as descriptor. Unless of course for this particular use a
> <map:parameter name="descriptor".../> is specified.
Ah, you mean that a Action could be configured to state the default
behaviour but should be able to parametrize it for a single run/usage.
Something that the TraxTransformer already does with the <use-store/>,
etc. configuration options.
>
> > > If we can agree on this, it would be a duplication of effort to have
> > > every action implement parsing the configuration itself. This is the
> > > reason why I suggested to put this into AbstractAction.
> >
> > I think it is not possible because different actions need different
> > configuration. And as said earlier the element <parameter> isn't very
> > elegant here.
>
> Sure. But I believe most could do with the provided method, modified
> to use element name + element value instead of <parameter>. If more is
> needed, i.e. nested configurations, it would be easy to override the
> method. But you're right, some actions need no configuration at all.
>
> So, I'll move the configure method from AbstractAction to ComposerAction?
No, simply clean the configure method as it was before.
> 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.
> 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.
>
> 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.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
