I had started on auto-generating classes based on a database table as a proof of concept, but I haven't worked on it anymore since I found out it about Torque, Castor, etc. I liked the idea of keeping things very simple and generating jdbc code that you would have written yourself so it would be easy to look at and edit. I thought that one of the transformation packages could be used to copy to and from the ActionForm and the PK and Data classes.
http://home.earthlink.net/~dwinterfeldt/generator/ Overview http://home.earthlink.net/~dwinterfeldt/generator/overview.html I just thought I'd mention this in case you want to look at it. David --- Bryan Field-Elliot <[EMAIL PROTECTED]> wrote: > First, let me clarify, I'm not interested in > re-inventing the connection > pool. > > What I _am_ interested in, is a simple framework > which maps JDBC tables > to Java classes, with getters and setters, which > roughly meets these > goals: > > - Ability to easy create a new class which models a > table (or, if not a > POJO (Plain Old Java Object), then the new DynaBean) > - Easily model the concepts of a "finder" (execute a > query, return many > entity objects) > - Easily handle creations/deletions/updates, with > the framework > communicating your changes to the database > - Easily wrap up transactions from within Struts' > way of doing things > (begin tran before executing an Action, and commit > tran at it's > conclusion; rollback if an exception is thrown; > allow the Action to > explicitly rollback). > - Easily allow Struts Actions to hand these entities > (or collections of > them) to the View for rendering into HTML etc -- in > a way that makes > these entities read-only and detached > - Easily handle some of the more ugly, common tasks > in JDBC development > - namely, (1) primary key generation, and (2) > optimistic concurrency > locking > - Keep It Simple - this should NOT balloon into a > huge framework - it's > source should always be readable and understandable > by most - if you > need something more complex, go get JBoss or one of > the bigger > frameworks recently mentioned here. > > Other "sliding scale" factors include: > - How easy do you want to make it for developers to > build their entity > classes? The easier you make it, the more complex > the underlying > framework is likely to become. Do you do automatic > class generation > (from an XML file), or can you declare everything > within your own > classes (which perhaps extend a framework base > class)? > - Is there automatic "change detection" (ala EJB), > or must the developer > execute some kind of "update()" method after > changing a bean? Automatic > change detection would give the developer one less > thing to > remember/worry about, however, it can really balloon > the framework. > Personally I lean towards leaving out change > detection and letting the > user (me) remember to call update() before my bean > goes out of scope. > > Everyone (and every framework) strikes its own > balance, roughly, between > ease of use vs. framework simplicity. I've found a > balance point which > feels right to me but may not for others. I'd be > happy to put something > up here in the next few days to show where it lies, > if there's interest. > If, instead, I get cries of "stop reinventing the > wheel" then perhaps it > had better be put to rest. But in any case I do see > value in providing > the option of a Struts-friendly, > far-lighter-than-EJB (but more meaty > than simple JDBC wrapping) framework. > > Bryan > > > On Mon, 2001-12-17 at 11:40, Jason van Zyl wrote: > > On 12/17/01 1:35 PM, "Bryan Field-Elliot" > <[EMAIL PROTECTED]> wrote: > > > Well, I certainly don't like to see work > duplicated, and it seems that > > there are many other efforts under way (some > of them within Jakarta) to > > build a generic persistence framework. That > said, however, some > > additional considerations might still point > towards the usefulness of a > > new framework: > > > > That's certainly true, there are a couple webapp > frameworks here, three > connection pools, two service frameworks and now > one in the sandbox so if > you need a persistence layer and you feel none > of them satisfy your needs > than you won't be starting any new trends. If > you find it easier working in > a smaller group with people that have similar > needs (which I find working > within the turbine world, and you may find the > same working with struts > developers) than that's what you have to do. No > one here has really tried > that hard to unify everything, and in reality > that's probably not ever going > to happen and diversity is a great thing > > If you have ideas, than put them in the sandbox > and let people look at them. > > -- > > jvz. > > Jason van Zyl > > http://tambora.zenplex.org > http://jakarta.apache.org/turbine > http://jakarta.apache.org/velocity > http://jakarta.apache.org/alexandria > http://jakarta.apache.org/commons > > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
