on 6/21/03 10:55 AM Christopher Oliver wrote:
<snip/>
2) getComponent() returns an avalon component which is not a sitemap component.
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 thrown.
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 http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105407572313285&w=2)
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 possible/desirable
in flow?
I guess a third option is adding getAction() (instead of callAction() ) ??
Geoff
