cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leon Widdershoven <>
Subject Re: [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)
Date Mon, 19 Apr 2004 21:01:04 GMT
Guido Casper wrote:

> Yes that might be one reason. Another one IMO is that it's much easier
> to (conceptually) come up with a reusable sitemap component (being a
> specialized thing) than it is to come up with a reusable flow component.
> Guido
I think that is the true question.
I am writing an application which gets an excel spreadsheet with 
this information must be read into data structures, and compared with 
databaserecords, and then  merged.  I use flow to get the user data.  I have
tried to write the total application entirely in Javascript (with of 
course HSSF
Java classes). It works, but is not really maintable.
So I wrote a reusable flow component called a Java Package. The main
class gets the uploaded spreadsheet and all flags, and returns errors or OK.
It can be called from any flowscript program, the classes can be configured,
it can be called by Java classes. How much more reusable can you get?

And at the same time I think this is not what flowscript developers call
reusable. What is the characteristic of a reusable flowscript component,
defined in a way a user can understand?
For cocoon components that's easy. Implement a particular interface and
it is a particular kind of component. But flowscript is just much more free
on the one side, and in other ways a bit more restricted.

>> I think you could slowly move towards enforcing a FOM only access to
>> Cocoon; maybe start with two levels of access: a default FOM only and a
>> "RAD flag" (developer_mode='true') that be configured to say to Cocoon
>> that a developer wants to allow script X to have access outside of the
>> FOM model ?
No, please no. It is hard enough to find  components/scripts that do 
what you
want them to do - without reinventing the wheel. It really is not a good 
to artificially limit access to ready-made logic and thus forcing users 
to either
hack the cocoon sources, or to reinvent the wheel.

What you can say is that particular scripts should be considered private 
or protected
to indicate that their contract may change at any time without notice 
and that it
is thus very unwise to build a system based on that. (Yes, like Java).

A protected script also makes sense if it manages a resource which must 
be called
only when particular demands have been met, or which may have side 
effects on the
fllowscript environment.

But both such cases would be to protect the user, and not to force users to
a certain development model favoured by the developer. The developer may
well be right in his opinions, but users come from different backgrounds and
would not understand they be limited because their way is not neat.

I am sorry if this sounds to harsh, but it really *is* hard enough to 
find functions which
do what you want them to do. If you then find out those functions are 
blocked for
some unfathomable (ideologic) reason, you would not be glad.

If I read to much in the statement above I am sorry. But I strongly feel 
that flow
is a more powerfull  technology than xsp for many applications, and that it
should be kept simple for users. And simple is not a limited set of 
functions, but
a feature rich environment which allows you to do what you want without 
to much
Java (a bit like xsp is now),


View raw message