Maybe we should put together our efforts to get this thing working and to help other people with a wiki page.
I need to tell I am newbie in OJB too. Maybe 1 or 2 days ahead in some cases, but this is nothing.
Pure understatement :)
We have at least our own application running with OJB. We can retrieve lists or single objects from the db and display them with Woody, we can store them back and delete them. We only have still a problem with object identity,
I think there is an old bug in JDO implementation in OJB related to indetities. We fight with this problem 2 weeks with no results, then we decided to switch to PB implementation. But let the open door to rewrote the code when JDO will be avaliable.
We don't JDO at all so it can't be a JDO bug :) It was also not a bug in OJB, but in my binding file. The id of the object was read/write, I changed it, now it works. (It's only strange IMO that updating an object with resetting the id to 0 stores the object correctly (probably because of object identity in the Java sense) and adds a new object (object identity in the ojb sense = new primary key) additionally - that might be a bug in OTM.)
so that storing does indeed create a new object in db, but that's another problem we didn't have a closer look yesterday evening.
We started also with OJB/JDO and had bad feelings when we saw that we have to maintain at least two files (package.jdo, repository.xml) to get it working. The reason for it is that JDO and OJB are two different products, OJB provides only a plugin for Sun JDO at the moment, but both must get their configuration. Though it's easy to write a stylesheet that converts one format into the other I tried to use only JDO.
While writing the code in Druid, I noted that repository.xml has far more info that the .jdo onces.
Indeed.
In fact after querying on the OJB maillist I noted we don't need to put too much info inside the .jdo. AFAIK, the only need info in .jdo is the info that currently druid put on the .jdo files.
Don't know what Druid puts into it, but you only need the information for the JDO enhancing and the class usage at runtime. The file is completely not interesting for OJB.
But JDO is just the API, the SPI must be provided by the database vendor and as there are probably not that much for a specific at the moment, you need OJB. Then we found out that the JDO implementation has a performance problem: Retrieving 20 rows out of 6.000 in a db leads to instantiation of all 6.000 objects, they are filtered by JDO. That's not a problem of OJB, it's just how Sun JDO works. So we were back nearly to the beginning.
Hmm.. switching between JDO->(PB|OTM|ODMG) is not too painfull. This in one of the best features of OJB at all.
Hope so :)
Now the application itself. I don't love the idea of accessing the persistence layer from the flow/controller layer directly. We access it only from the application layer to have obvious tiers. We have a DAOFactory that returns DAOs (e.g. either JDO or OTM), the implementation of the persistence framework access is abstracted.
We choosed to have DAO classes with static methods, that way we don't need to create too many DAO objects. Between Flow and DAO classes fly the Beans. Some of them are BeanList. They are easily passed to the cforms using the framework binding.
Similar to ours, but in our approach the flow has no access to the persistence layer. The request goes through the business logic layer.
I am not sure if this is the best approach, but it works. I will be glad if we can comment about what are the pros and the cons of Joerg approach vs. this approach. I am not a Java or OO guru. Comments are very welcome.
I guess it just depends. We will have much business logic, so a layered architecture is important. A direct access from flow to persistence layer will be dangerous in this case.
In theory we can switch to Castor, Hibernate or what else without touching the application layer.
Can you explain what is the application layer? I am confused here. Is the application layer the view in the MVC paradigm?
MVC is a bit coarse-grained (if that's the correct word?) IMO. A good architecture needs more layers. A searched around using Google about application layer. In some cases the word is used synonymous to business logic layer, on other pages it's between presentation layer and business logic layer. What I meant above was indeed the business logic layer.
Each object specific DAO will provide different methods for retrieving, storing, deleting etc. As the layers below the flow layer are no Avalon components and not in relation to Cocoon, but "Plain Old Java" we kicked out Cocoon OJB block completely and just use OJB. If this was a good decision we will see.
I thought to do this too. In fact the first experiment was using directly OJB in Cocoon:
http://wiki.cocoondev.org/Wiki.jsp?page=OJBWithJDO
Later, I thought that the best approach was to use a common factory for all the servlet instead of using OJB directly.
I don't understand your objection here, maybe it's only a misinterpretation. We use a factory too that creates a specific DAO. But the usage of the DAO is completely independent on its implementation and so we don't use OJB directly neither.
But it won't be that difficult to switch the datasource back to Avalon/Cocoon in OJB properties file.
AFAIK, using OJB as an avalon component is better from an architectural view because it follow the same approach as the other components. AFAIK, we can also use other components outside Avalon schema, but this is rather not desired.
There are more layers that had to be made Avalon components. We decided to avoid this effort for the beginning.
BTW, we package all classes, configuration files and so on into our application JAR, deploy it in WEB-INF/lib and it works without any problem.
I use 2 jar approach, one for beans and other for DAO. BTW, I prefer to call them "Handlers" because they are more or less oriented to handle data from/to CForms forms.
Might be again a misinterpretation but DAO do not stand in any relation to CForms. They handle just the the data access and so they are Data Access Objects.
Instead of writing the code in Flow files, I prefer to use Flow just as a true controller (shorter files). It does not do the work just decide what to do with the recieved request.
Same here.
To me Flow is just the controller that recieve request and decides where to send the beans to be processed.
For me the flow does not decide even this. The flow delegates a request to the business logic and gets and object at a specific place. This one the flow can bind to the form.
Joerg
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
