cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Haul <>
Subject Re: frustration with cocoon [please help]
Date Wed, 03 Dec 2003 10:01:20 GMT
Geoff Howard wrote:

> Michael Wolf wrote:
>> 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.
Last time I checked it appeared that all support code is still there. 
But then I didn't test it.

>> 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.
Probably because this touches basic Avalon knowledge and the Avalon site 
is the best place to find that.
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 
     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.


View raw message