cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Discussion of Flow Issues
Date Wed, 19 Mar 2003 00:25:21 GMT
Pier Fumagalli wrote:
> On 18/3/03 23:00, "Stefano Mazzocchi" <> wrote:
>>But I have the impression i didn't understand what Pier was implying
>>because I'm sure he would not propose to force people to write that much
>>java gluecode just for everyday FOM usage.
>>Pier, can you elaborate more on what you wanted to say above? TIA
> For those object on which we want to tightly control the behavior, for
> example, you want to be able from a flow script to retrieve the "cocoon"
> instance, but not to set it (readonly attribute Cocoon cocoon in IDL).
> I'd settle with writing a bunch of "glue-code" for our (work) applications,
> if that allows me to clearly define the boundaries of what flow-script
> writers can have access to: I can write the glue and have much more
> flexibility writing my backend in Java knowing that anyway, my team won't be
> able to mess around with it...

Right. The goal of the FOM is to make public those methods that are 
"safe" from an architectural point of view for script kiddies to mess 
around with.

The more dangerously abused an internal public method is, the harder 
will be for script kiddies to get it from the flow.

This should (hopefully) reduce scripting abuse.

Is anybody against this general approach?


View raw message