Announce: MollyPages -- O/R mapping tool & server-side framework


Web tier: servlets, JSP, Web frameworks: Announce: MollyPages -- O/R mapping tool & server-side framework

  1. 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. 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. You are supposed to have fun using this framework and not stress out about any "right/wrong" way of doing things. Best regards, -j
  2. 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 ..)
  3. 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) 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?