> yeah, I'm porting the TheServerSide.com portal to use XDoclet. I had > some problems, but got the latest CVS, got some more problems, and it > forced me to change into a structure that was superior to what I had > intended to do in the first place :-)
And what were the problems? Maybe we could fix it? Hope it's now ok specially with this new superior architecture :o) Everyone knows that XDoclet leads to superior architectures :-)))) > At first I wanted to have each entity be two classes: XBean, containing > the business logic and abstract get/sets, and then XJDBC which > subclasses XBean and implements ejbLoad/ejbStore for BMP. But that > didn't quite work, so instead I made a superclass EntitySupport that > XBean could extend, and in EntitySupport.ejbLoad/ejbStore I delegate to > a DAO object that handles the JDBC. This is really cool because it means > that I can very easily switch persistence mechanism by simply making a > factory mechanism for the DAO handlers :-) So, for example, during dev > I'd use a simple XML storage, or db4o, and then for production I'd > switch to JDBC, but without having to change my code at all. Yup. Actually I'm thinking of porting our app to use MVCSoft under websphere. I'm getting sick of websphere's chunkiness :-) What a good thing was hot-deployment! Sadly it's not yet invented for WebsPhere!!! > Aaaanyway. Back to coding. Back to stone age ;-) Ara. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
