On Wed, 14 Jun 2000, NABETH Thierry wrote: > Hello, > > I must say I am a little bit worry that Jetspeed evolves too much towards > the old software architecture in which you have a kind of central relational > database around which the application are developed. (and as consequence > complexity, and lack of flexibility). > Hello. I am Jeff and I am the active maintainer of the calendar code (the most db intensive part of Jetspeed). You have brought up some good points. You can add lack of maintainability to that list too. We fully understand that if DB persistence is not done right it can mean a virtual (make that very real nightmare) for such things as flexibility, complexity, and maintainability. I once inherited an application with hard coded db logic in it accessors. This was horrible and the main reason why I didnt even choose a persitnece mechanism until May. I wanted to get the development of the business objects fleshed out before thinking about how to get them in the DB > (Note that I very much like the architecture of Jetspeed right now, because > it separate very well the logic of the application and the presentation). > > > Have someone thought of going more towards the idea of using a model of > persistance ? > (this way the database is directly an extension of the object oriented > "paradigm"). > The current model I am using for persistence is the Peer model. More specifically Turbine's BasePeer classes. In this model each business object that needs persistence has a corresponding class that takes care of the persistence issues. The project code (org.apache.jetspeed.project) seems to be building its own persistence mechanism which is maintained by Sandy Metzger. I AM -1 ON THIS. As are everyone else who has expressed an opinion. It has been my impression from Kevin's email that project would not be included in a release until it had better integration with Jetspeed/Turbine and a more standard DB persistence model. > For instance have a look at this article: > > "Objects in the Database: An overview of Sun's Java Data Objects > specification" > by David Jordan > Java Report, June 2000 > The main objective of JDO (JAVA DATA Objects) is to provide support for > transparent object-level persistence of Java objects, so that Java class > developers need not provide their own persistence support. > The JDO API is defined such that applications are independent of the > particular > data store being used by a JDO implementation. Implementations are planned > for > file systems, hierarchical, relational, and object databases. These will be > available in the following Java environments. > http://www.javareport.com/html/from_pages/column.cfm > I will read this... > Castor (Exolab) seems also to go to this direction with > Castor JDO: Java object persistence to RDBMS > http://castor.exolab.org/JDO > > We are watching Castor closely, but it currently (at least the last time I checked) did not support one-to-many and many-to-many relationships. Furthermore, there is a new initiative in Turbine to create a BasePeer code generator that would automatically generate a specific peer object from an xml file. This seems propmising. With the peer model database specific coding issues should not ripple past the peer object. ----------- -------- ____ | Business|________|Peer |_______|DB| | Object | |Object| --- ___________ ________ | Database issues are not seen from this point onB > I would also like to mention another open source initiative called Zope > http://www.zope.org/ > in which an object database is directly integrated into the system. > Zope is writen on top of python, and does not really rely on xml, > which is why I believe the future of Zope is relatively limited. > However, zope has a lot of flexibility I would have liked to find > in Jetspeed. > You can directly browse your (OO) database with a web browser > as you would do with a filesystem. (except that the categories of objects > are much richer and you can create your own categories). > Zope does seem to have quite a following, but I have really checked it out. It must be decent then, however, I am not a big fan of python. On a side not I have a friend here in Delaware I meet at the LUG who is a Zope programmer. You know Open source is catching on when there are two OS programmers in DE. Jeff Prickett [EMAIL PROTECTED] -- -------------------------------------------------------------- Please read the FAQ! <http://java.apache.org/faq/> To subscribe: [EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: <http://java.apache.org/main/mail.html> Problems?: [EMAIL PROTECTED]
