Le 6 mai 04, � 09:44, Derek Hohls a �crit :
Bertand
Is there not a difference between a Java "business
object" (which I assume in a Cocoon app will be a
POJO - even though I do not now know where and
how to create this...) and "data access object" - at
least that what the Core J2EE patterns imply
http://java.sun.com/blueprints/corej2eepatterns/Patterns/ DataAccessObject.html
To be strict, yes: a DAO's role would be to interface with a database, save and retrieve data, that's it.
Whereas a "business object" usually means an object that sits on top of DAOs (or other data access methods) and implements business rules, aggregations, etc.
But I think this is not terribly important when talking about how to interface Cocoon with Java objects.
Basically, if you're using Flow as a front-end to business logic and/or data access stuff written in java, the Flow needs to:
1) Access the java objects
2) tell them to load the required data
3) manipulate the data (maybe with CForms) - the java objects are most often not used for this step
4) tell the java objects to save the modified data
That's it, and this is demonstrated (although in a very simple and limited way) by the bean editor app in the supersonic block.
The objects shown there do not use a database, the data is just being held in memory. But adding database load/save would happen only in the java world, without requiring further interaction with Flow (other than Flow calling the load/save methods at the right times).
Also, this example app uses a simple instantiation for 1), but if you really make your java objects play with the Cocoon framework, you'd want to use the Avalon object lookup mechanisms for this. It's a bit more complicated but not that much.
Hope this helps!
-Bertrand
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
