on 5/27/03 1:05 PM Geoff Howard wrote: > At 01:05 PM 5/27/2003, Stefano wrote: > >>on 5/27/03 4:06 AM Sylvain Wallez wrote: > > > .... > > >>>>void callAction(name,map) -> invoques the action indicated by the given >>>>name and pass the given map as model >>>> >>>>NOTE: I personally believe that the getComponent() method removes all >>>>needs for the callAction() method. I foresee a future where the >>>>callAction() method will be deprecated. I would personally go the extra >>>>mile and avoid having it there altogether, but since there is no easy >>>>way to plugin new avalon components at runtime (at least, not as easier >>>>as plugging in different actions into the sitemap), I'm in favor of >>>>leaving it for now, until 'real blocks' will make it unnecessary. >>> >>>Same feeling. So what about removing it now ? We can also consider that >>>the current state of things is that components are "semi-pluggable" : we >>>cannot add new classes to the classpath dynamically, but we can declare >>>new components, and particularily actions, dynamically just by changing >>>the sitemap. So I don't see the real need for callAction(). >> >>I'm all in favor or removing this. What do others think? > > > Can you clarify how one would lookup and call an action without it?
In theory, the above is *exactly* done to prevent you from being able to call an action but rather force people to move into a more general component-oriented approach. > What > is the "id" of a component? It's role? It's sitemap hint? It's fully > qualified classname? I get the feeling it's none of these, or some > combination of these? It is currently undefied and left undefined on purpose. The FOM should not care about this, it's a contract between you and the component container that is totally transparent to the FOM. We'll discuss component loading after we are doing with the FOM. > The migration path out of actions will be less painful if at first people > can easily call their action code from the flow (obvious to you I'm sure). This is why I proposed to keep callAction() there, but Sylvain thought about removing it and I'm happy if we do. > Understanding clearly how this is to be done will help me get a feel for > how painful this will be for non-insiders. The migration path between Actions and flow is: move away from actions. Who? piece of cake: instead of using the Action interface, just implement your own service interface. that's it. Java components give services and these components should not be connected to cocoon. If you want, you can write a thin action wrapper around those components, but once you have the flow, I really don't see why you would go that way. -- Stefano.
