I, as a user, do not differentiate between Components and utility classes and functions. I think that when a cocoon developer hears Component, (s)he thinks of classes which obey some sort of contract by implementing an interface.
If I, as a user, think of a component it is a part that does something and is easily integrated into the flowscript.
And example for Javascript flowscript is of course woody.js. This integrates fabulously with flowscript.
Unfortunately, the same does not hold for database actions. As I user, I could not find a way to access databases without just using the classes from java.sql, though I did manage to get a Connection from the pool from the manager. As a *hacker* I used parts of the samples plock (PetStore); the sample block contains an excellent module, part of the petstore, to access databases and represent resultsets.
And what I'm wondering is why such a usefull component for an example is part of -of all things - an example block in stead of an optional JavaScript/Database block.
I have the feeling that people might be more willing to make components for flowscript (and the same would probably hold for other flow languages) if components did not look so application specific. I use Dababase.js; but the sources are part of the samples, so I for one have the feeling it is a totally unsupported module.
In short, I think existing components could be more clearly presented as components for re-use. I have the feeling there are quite a lot of usefull components 'out there', but it's hard to get a list of the available modules for flowscript. In contrast, it's quite easy to get such a list for xsp, which is why a lot of people just use xsp even when flowscript would be better suited.
That was my optinion. I do not own asbestos underware but I *can* duck.
Leon
