cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <>
Subject Re: FOM implementation
Date Thu, 26 Jun 2003 14:16:07 GMT
At 11:27 PM 6/25/2003, Stefano wrote:
>on 6/21/03 10:55 AM Christopher Oliver wrote:


>2) getComponent() returns an avalon component which is not a sitemap
>Basically, it has to ask to the cocoon component manager to return the
>component identified with the given role and check if it doesn't
>implement "SitemapModelComponent", in which case an exception should be
>What do you think?

I'm going to ask again about reusing code currently in actions - we talked
about this before but I think I can explain a little better what I was
thinking.  (see

Scenario: you have code in actions and want to quickly migrate to flow,
abandoning the "action contract" (the null/map return from act() ) but
don't want to recode all existing actions to do so.  If each action already
has public methods which it called internally from act() (perhaps because you
wanted to be ready for a transition to flow) you already have your generic
avalon component suitable for use in the flow - just don't call act, but your
various other methods.

Since the discussion linked above, it seems that getComponent() is now
taking a role as it's id - this was at some point not a given.  So how
do you locate your component (ex-action) if it does not provide a specific
ROLE, but just inherits it from some superclass?  I see two options:

- go back and add a specific ROLE to each component?  involves (admittedly
trivial) modification to each class and recompiling them all.  Does this mean
it must go in cocoon.xconf (surely this must be "yes")
- look it up via the sitemap hint - but that is probably not 
in flow?

I guess a third option is adding getAction() (instead of callAction() ) ??


View raw message