Hi Jim Thanks for your advice. If it only takes three hours it would definitely be worth the hassle instead of maintaining two object models in parallel. I'll give it a try.
/johan jim moore wrote: > It seems to me that complicating your application (the dual model > layers) just to get Maverick to work for you is a bad way to go (the > whole point of Maverick is to simplify web application development). > Particularly when there is a far more workable solution that would have > the added benefit of adding to the project/community, namely creating a > custom view to use betwixt or java xml view. Despite your never having > looked "under the hood", I don't think you'll have too much trouble > writing a custom view--I think it took me about 2 or 3 hours at most to > write the first iteration of opt-fop (which was originally a custom > view--now it is a transform). And that time included figuring out what > was going on under the hood.... > > --jim > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On Behalf Of Johan > Lundberg > Sent: Sunday, September 08, 2002 5:11 PM > To: [EMAIL PROTECTED] > Subject: [Mav-user] cyclic reference graphs in opt-domify > > > Hi > > Background: > I am using Maverick in combination with Torque (Jakarta project), which > is a Java layer that simplifies DB-access for a Java programmer. Torque > automagically gives me Java beans from a DB-schema. I am using the > opt-domify package that is provided together with Maverick. > > The problem: > The problem occurs when my torque generated Java beans have cyclic > reference graphs or methods like getCopyOfBean(). The XML-tree that is > generated will appear to continue on and on and on and on, until I get a > > 'out of memory error'. > > Possible solutions: > Jeff hinted me about the possibility to implement a new ViewFactory for > Betwixt (Jakarta project) or 'Java XML View' (Sourceforge). These two > packages can solve the issue with cyclic reference graphs. I am just a > Maverick user and have never looked under the hood, so I don't know what > > kind of effort that takes but it seems scary ;) > > The other solution could be to have a model of beans for the Maverick > WEB-layer and one model for the DB-layer. Then it would be easier to > avoid cyclic reference graphs since the Maverick WEB-layer beans could > be filled with data in a controlled way. Unfortunately, this would > create some overhead and also slow down the application. > > Why ask the list?: > I am sure that some of you have run into the same problem, which should > also occur when using EJBs which are referencing each other. I am > curious to get info about what would be the best way to solve this. > > /johan > > > > ------------------------------------------------------- > This sf.net email is sponsored by: OSDN - Tired of that same old cell > phone? Get a new here for FREE! > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > _______________________________________________ > Mav-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/mav-user > Archives are available at http://www.mail-archive.com/ > > > > ------------------------------------------------------- > This sf.net email is sponsored by: OSDN - Tired of that same old > cell phone? Get a new here for FREE! > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > _______________________________________________ > Mav-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/mav-user > Archives are available at http://www.mail-archive.com/ > > > ------------------------------------------------------- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 _______________________________________________ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user Archives are available at http://www.mail-archive.com/
