on 5/27/03 2:33 AM Bertrand Delacretaz wrote:
<snips cause="agree or dont't understand implications enough to talk"/>
Le Mardi, 27 mai 2003, à 08:44 Europe/Zurich, Stefano Mazzocchi a écrit :
... 2) design for safety: the flow will be a center of abuse because people will find it easier to write longer flows than to restructure their business logic into components. We must make all possible efforts to reduce this from happening....+1.
This is very important so that Flow does not become the next JSP or ASP ;-)
... Object getComponent(id) -> obtains the component indicated by the given ID...Does this mean *any* Component, or do you foresee a way for Components to say if they're made available in the FOM or not? Making everything accessible might also lead to easy abuse IMHO.
This is another concern entirely. We are currently focusing on the FOM, that is, on the contracts between the two layers.
Obviously, the flow will not have access to *all* components, but only to components that will be "flow-available".
Ah, here's the reason of my misunderstanding about components. But how will we decide which will be the "good" components that will be flow-available ?
On the subject of abuse : flowscript is a perfect tool for RAD. Setting up a demo in hours instead of days with some "abusing" flowscript is a real bonus when you have to convince a customer. So constraining it too much may kill a important benefit of Cocoon compared to other frameworks when it comes to use it to gain a project.
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
