I think that is the true question.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 am writing an application which gets an excel spreadsheet with information;
this information must be read into data structures, and compared with existing
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.
No, please no. It is hard enough to find components/scripts that do what you
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 ?
want them to do - without reinventing the wheel. It really is not a good idea
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),
Leon
