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/
