cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] FOM
Date Tue, 27 May 2003 21:30:13 GMT
Stefano Mazzocchi wrote:

>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....
>>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 Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message