On Mon, Apr 19, 2004 at 09:01:28AM +0200, Leon Widdershoven wrote:
Hi,
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.
because it is a totally unsupported module. Long time ago it was considered a bad practice to call actions from flow so the new FOM does not have it. It results in the fact that you are not able to use ESQL if you use a flow application. ESQL is lost and you do not have any substitute (the database.js you mention is considered a prototype only). And though all developers say : use O/R tools I started from simple xsps because cocoon itself was to much for me to handle at once. After some prototypes I switched to Hibernate and would never go back to ESQL but still I recommend to all my friends to start simple with esql.
As I have written in some previous post: with flowscript you gain a lot of
freedom and make development much simpler but because of lack of database
abstraction language you have to use components with pure JDBC which makes it
a lot harder in the business layer!
The best way integrating database support in Flowscript is using an *O/R-mapper*. If this is too complicated I would recommend a general database component. To get them we could make the ModularDatabaseActions more general and create a ModulareDatabaseComponent which can either be integrated into your applications using Actions (being completly backwards compatible with the existing actions) or Flowscript. I think it shouldn't be too complicated to create those components (at least with the help of Chris H. ;-)
WDOT, is it worth doing the refactoring?
-- Reinhard
