Announce: The release of new open-source O/R mapping tool. - Simple (no xml configuration ! yay). - been tested with both postgres and mysql. - used in production enviroments so the generated code has most bugs squeezed out by now. - No middle-tier games and (poorly) replicating transacations that best belong to the database. http://www.mollypages.org/dbo/ Also, released, a sister framework for server side pages. - clean syntax (look, ma, no "shift" key for open/close tags). - hash escapes (to HTML) from within java code/loops. - heredoc (unparsed) sections. - easily modifiable and well documented recursive-descent parser. So you can add/modify the open/close tags for different sections to whatever you please. http://www.mollypages.org/page/ You are supposed to have fun using this framework and not stress out about any "right/wrong" way of doing things. Best regards, -j
- Posted by: java designer
- Posted on: August 18 2007 15:06 EDT
- Re: Announce: MollyPages -- O/R mapping tool & server-side frame by Jeryl Cook on August 28 2007 00:25 EDT
- Re: Announce: MollyPages -- O/R mapping tool & server-side framework by David López on September 02 2007 05:56 EDT
nice work... but what are the advantages compared to already well used and liked O/R mapping frameworks...umm Hibernate?(XML isn't an issue, you use xDoclet ..)
Looking at the final objects created, there are some interesting methods found to operate on the actual persistent beans, such as: mollytestMgr.delete(Connection con, mollytest bean) mollytestMgr.save(Connection con, mollytest bean) mollytestMgr.update(Connection con, mollytest bean, int uid) Those methods are fashioned as in the structured pre-object-orientation days, when the data where stored in structures, whereas the methods are placed somewhere else. Following the very object orientation principles it shows evident that all those methods are concerned to mollytest class instead of mollytestMgr class. I very often find this problem in many other O/R mapping frameworks. One of the aims of OO is to model the objects in a natural way, where the client code sends the order to the object itself. What about refactoring the methods in order follow the OO principles?