Michael Wolf wrote:Last time I checked it appeared that all support code is still there. But then I didn't test it.
Now the act method doesn't work anymore. In the documentation it is still recommended to use the modular database actions from the flow, but nowhere is explained how it is done.
Probably because this touches basic Avalon knowledge and the Avalon site is the best place to find that.Then I've found mails where someone states that there is no need for the legacy script and one should be able to use the actions via the getComponent method.
But, of course, nowhere in the documentation is explained how to do it.
After posting in this mailing-list I got a hint how to access the action using the getComponent method.
AFAIK using action without the support boils down to the following problems:
- it's a multi step process instead of just calling act(): getComponent, call component, release component
- visibility: if the action is declared in a sub sitemap, it will not be visible to flow. This can be circumvented
by declaring it in root sitemap or even cocoon.xconf.
- parameters for act() signature:
- Redirector does not make much sense from flow. However, a new instance can easily be created.
- Parameters need some conversion to easily set them from ECMA script or the use of a little bit more
JAVA types. Remember that you can create instances of any JAVA type in ECMS script. There are
still conversion methods contained in the Cocoon object BTW.
- src is hardly used, mainly for actions written in other languages than JAVA.
- objectModel is a little more difficult since here start the area where we have cut down the FOM to make
bad things harder in flow :-| I believe it should be obtainable by ContextHelper.getObjectModel(cocoon.getContext())
or the like.
- SourceResolver is probably hardest. It has been discussed to make this available through the component
manager. In that case it could be obtained by cocoon.getComponent(SourceResolver.ROLE). If this is not
the case -- well, then it's an open issue that will be closed when someone finds the time for it....
Now, your particular case is really about out of the box database components accessible in flow - the fact that this historically was only available in actions is coincidence. There are a lot of different opinions here about what Cocoon should provide. There is a lot of movement toward providing easy integration with O/R projects like OJB. I personally feel it will also be important to have something like the modular database actions (perhaps even keeping much of its code) as standard components accessible from the flow. I don't have time to work on that, and don't know if others have the same view, but I see it as a need.
Well, it's on my schedule. But then I belive a O/R mapping is much more elegant and the actions are just what I like
to call a "poor man's O/R bridge". Plus the interest in this seems to be quite limited....
But now there is the act method of the action with its parameters. Again, there is no information how to do this.
Now, about calling the act method - you should be able to come up with all the objects it needs and call it right from flow. In fact, you may be able to pass in null as some of the objects if you're sure it the mod-db actions don't use them. Come to think of it, a quick and dirty way to find out what they (the actions) need is to pass in all parameters as null and fix each specific problem as it arises. It won't get you a PhD in Computer Science but it's crazy enough that it just may work.
SourceResolver is needed to load the description files, objectModel needs to be passed to the modules for obtaining
e.g. request parameters. Parameters contain configuration of the action. Most (all?) can be set when declaring the action.
For two weeks I tried to get the modular database actions running from the flowscript as it is recommended in the modular database action sample shipped with the 2.1.2 cocoon version.
I've not seen that recommendation personally - as discussed many would not recommend it. Your other options are
Me neither.
really to
- refactor the actions to run as standalone components,
- write your own jdbc code in components,
- totally switch your design to work with the (still experimental?) ojb block
- don't use flow in that part of your project.
Given those options, I'd say you'll probably have the best luck with the path you've been trying but that's just my quick opinion.
Another hint is to look at the GT2003 presentation on database integration with Cocoon. It doesn't
tell you everything but has an overview on your options.
Chris.
