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.
>
> > 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.
> > 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?
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?
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.
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?
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]
