Stefano, Can you say how you plan to build this FOM? You've specified what is needed, but not _how_ you think it should be done.
Is it possible that others could help, and thus get it done quicker? Especially if you say how it should be done. Regards, Upayavira On 16 Jun 2003 at 17:23, Reinhard Pötz wrote: > > From: Stefano Mazzocchi > > <skip/> > > > Chris suggests we release 2.1 without bothering the FOM because it > > will need time to adjust anyway. I agree, but what really worries me > > is the fact that we *already* know it's going to change radically > > and releasing such a bad contract is not going to be good publicity > > for cocoon in general from contract solidity perspective. > > > > you can mark it as beta as much as you like, but people are going to > > discover it, fall in love with it, use it for testing, then > > pressured by their bosses, put it in production, then ask support > > for it, or at least a back compatibility layer. > > > > Do you really want to force our users to go thru this? I don't. > > > That's exactly the point! The flow needs users that implement it in > many real life projects to make it stable from an implementation point > of view (altough I think it _is_ already very stable.). But this needs > a stable interface (FOM) because otherwise many users will hesitate to > use it in production and I learned in the past that only real life > problems can really challange a new concept or technology. > > And additionally I'm +1 for the evolutionary approach small to big > because it makes it easier to maintain your application in the future. > > - o - > > 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? > > > - 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? > > > - Should the flow _always_ be associated with a Session? > > > - 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 ... > > > - 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 > > > > 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? > > - Do we need access to the modules? Or is the prefered way using > getComponent( id ) in the future? > > > Are there any other open points? > > > Reinhard > PS: My time is very limited at the moment but I'm willing to help as > much as (and if) I can! > > > >
