On 18/3/03 23:00, "Stefano Mazzocchi" <[EMAIL PROTECTED]> 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?
Stefano.
