J. Wolfgang Kaltz wrote:
[...]
Regarding the exit usecase :
would it be possible to configure the exit usecase within the usecase
configuration, instead of the source code ?
For example, the delete group usecase has this code
setExitUsecase("admin.groups", null);
So this means the source code is dependant on the usecase name as
defined in cocoon.xconf. If we can avoid that, I think we should.
If we could configure it instead in the usecase configuration, for
example something like
<component-instance name="admin.deleteGroup" logger="lenya.admin"
class="org.apache.lenya.cms.ac.usecases.DeleteGroup">
<view template="admin/deleteGroup" menu="true">
<parameter name="tab" value="groups"/>
</view>
<exit name="admin.groups"/>
</component-instance>
that would avoid the Java code hard-wiring the name of the exit usecase.
That does make sense or am I missing something ?
Actually that was my first idea too (with a slightly different syntax):
> <component-instance name="admin.deleteGroup" logger="lenya.admin"
> class="org.apache.lenya.cms.ac.usecases.DeleteGroup">
> <view template="admin/deleteGroup" menu="true"
exit-usecase="admin.groups">
> <parameter name="tab" value="groups"/>
> </view>
> </component-instance>
But when I noticed that dynamic parameters have to be added in some
cases, I realized that we need a Java interface to this functionality
anyway.
I didn't add the configuration option, because I thought that a
mixture might be confusing. But maybe it would make sense to configure
the exit usecase name in cocoon.xconf (which would mean that all usecase
names are configured there) and the parameters in the Java code
(parameters are generally declared in the code)?
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
