The vote clearly indicates the community wants the "small -> big" approach. Chris has also removed his concerns. This gives us green light to go ahead and finish the FOM design as we proposed it.
on 6/16/03 10:23 AM Reinhard Pötz wrote: > So let's try to finish the FOM! > > First I summarized the agreed points here: > > [http://wiki.cocoondev.org/Wiki.jsp?page=FOM] > > > And after looking through the latest discussion of the FOM the open > points are: > > - Component loading > > Object getComponent(id) -> obtains the component indicated by the > given ID > > Here > [http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105405317918849&w=2] > Stefano wrote: "Obviously, the flow will not have access to *all* > components, > but only to components that will be 'flow-available'." > > Stefano, could you elaborate on this? > How would you make a component flow-available? How does this avoid > the > possible abuse of the control flow? I see two different types of components in Cocoon today: 1) general components (example: SaxParser) 2) sitemap components (example: FOPSerializer) I think the flow should have access only to the first family. This leaves one important problem: for the way cocoon is currently designed, it is not easy for a user to deploy a new general component inside cocoon since it has to modify the role descriptor that ECM (extended component manager) uses. There could be many ways to solve this, but I think the design of "real blocks"(tm) and the use of more modern component containers (such as fortress, for example) will remove this problem. Note that, from a strictly FOM point of view, how easy it is for the user to deply now general components is not a concern. Also note that it is not defined *HOW* the FOM will identify the component to be loaded. Thanks to weak typing, we don't have to care about this at this point. So, for today, the FOM should be implemented that only general components are loadable and they are identified thru their roles or their short names (as listed in the role file) > - stateful components -> how to release them? > > There have been two mails: > RR: > [http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105464984417883&w=2] > SW: > [http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105472379523896&w=2] > > Are there any more thoughts about this? Ricardo and I discussed this extensively a night ago. My proposal would be to add a call such as sendPageAndFinish() that would remove all the continuations from the tree and free all loaded components. but there are still a bunch of issues with the use of stateful components in a continuation-driven environment and I'm not sure we have enough information just yet to understand what is the best way to handle this. So, it would be best to let the flow writer take care of everything and provide a dispose() hook to the FOM, potentially deprecatable once we idenfity how to do transparent component garbage collection in a continuation-driven environment and stateful components that are not aware of this. Still, the mix between continuations-based state handling and other forms of state handling (say, transparent EJB transactionality, for example) will very likely become the single focus of future research in this community. > - Should the flow _always_ be associated with a Session? I haven't written a flowscript that didn't require, in some way or another, the availability of some statefulness on data and it seems to me as overkill to use full execution state preserving (and the URI-encoding of the continuation every time!) just for the data (besides, even today, if you want to keep global flow variables around, you have to enable sessions anyway) In general, it is true that continuations and sessions are different beasts, but in real life, continuations *extend* sessions since they provide the ability to save *even more* state than sessions. But in those situations where procedular flow is weak and navigation decisions are driven by user action and not by flow execution, continuations are overkill and sessions are still the preferred way to go. is there a real need for continuations without sessions? i really can't provide a meaningful example of this. so, I would say +1 to this. if you are against this, please speak up now. > - void callAction(name,map) -> invoques the action indicated by the > given name > and pass the given map as model > > Is there anybody against removing it? Is there a real need for it? > > I would say we should remove it and point people asking for > it to > [http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105407572313285&w=2]. > And if we want we can decide to add it to the FOM at every time ... Again, I'm in favor of removing this altogether, but I would like a vote on this as well. > - Context > Which methods are available? Especially do we need setAttribute( > name, value )? > > see: > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105405579422169&w=2 I would say: --attributes-- getAttribute(name) getAttributeNames() setAttribute(name,value) removeAttribute(name) --parameters-- getInitParameter(name) I see no need for the others methods to be explosed at the flow level. > And here some points that have not been discussed yet (or overlooked by > me): > > - What has happened with the continuation object? Don't we need it any > more? Uh, you're right. I overlooked that. I really have mixed feelings about this. Currently, the WebContinuation object is exposed to the FOM and used in system.js to implement sendPageAndWait(). I don't like this because it exposes too much of the continuation machinery internals to the flow layer. So, at least, if the continuation object is left, the ability to contruct a new continuation should not be exposed in the FOM. But at the same time, why would we need direct access to the continuation object? the only valid reason is to invalidate the continuation, but again, it feels kinda anti-scripting to have to go chasing the continuation and invalidate it. does anybody have a real-life example of the need for having access to the continuation object? > - Do we need access to the modules? what modules? > Or is the prefered way using > getComponent( id ) in the future? > > > Are there any other open points? Vadim suggested that we make the session object available as a property of the cocoon object instead thru the getSession() method and I agree that this might be desirable and provide consistency. Please, if we overlooked something, let us know so that we can finalize the FOM design and start implementing it. -- Stefano.
