Antonio Gallardo wrote:
Reinhard Poetz dijo:

I'm aware of the fact that there are many ways in Cocoon. I think that
we as community should give clear advice what's in our opinion the best
way. If I'm asked I say:

1. Enterprise Level ---> O/R-mapping, EJB

2. Simple Database Applications  with CRUD (create/update/delete)
                     --->  Flowscript and Database Component

With Groovy the (2) will be easier.


3. Publishing ---> SQLTransformer


I think (2) can be also be used with O/R mapping tool. Not sure what the
DB component is. In fact (and with my respect to ESQL developers) why
Cocoon will need to build another layer when there is OJB. Remeber OJB
allow you to play at 4 levels:

A-PersistenceBroker - A very simple API to deal with DB. With DB
transactions, but not object transactions
B-OTM - Object Transaction Manager. The same as above + Object Transaction.
C-ODMG
D-JDO

In this way OJB is not exclusive for big leaguers. You can use OJB in
minor applications too.

That's interesting. Would you care to explain to me what the difference between a DB transaction and an object transaction is?


<snip/>

You also asked how the DatabaseComponent which I'm thinking of could
work - here an example:

function myDBFunc() {
   var myDBComp = cocoon.getComponent("myDBComp");
   myDBComp.setMapping("mappingFile.xml");
   myDBComp.add("tableSet-A"); // tell the component which tableset to
use
   cocoon.sendPageAndWait("blabla", {});
}

I like that.




I will prefer OJB people to make what they do the best.

which is an O/R-mapper for which you need an object model, which you might not have (and maybe don't want to have).


BTW do you have an idea how OJB might work with Dynabeans (or XMLBeans)? (just thinking out loud again)

Guido

Is worth to make
another DB support in Cocoon anothe propietary API? AFAIK, Cocoon is the
"glue" for webapp needs. And here we will go to another area. Also, why
reinvent the wheel again?


Maybe the DatabaseComponent should support reading operations too.
The question is whether we don't duplicate the efforts of e.g. OJB with
this approach? The only difference is that you don't need Java objects ...




Best Regards,

Antonio Gallardo



-- Guido Casper ------------------------------------------------- S&N AG, Competence Center Open Source Tel.: +49-5251-1581-87 Klingenderstr. 5 mailto:[EMAIL PROTECTED] D-33100 Paderborn http://www.s-und-n.de -------------------------------------------------

Reply via email to