Field naming blows Form<->DAO mapping in practice.

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Field naming blows Form<->DAO mapping in practice.

Ahmed Mohombe
Hi,

As of javadocs, for the fields, the following is stated:
"The field name will be Java property representation of the given label"

I played a little more with Form<->DAO mapping and it doesn't seem to work right in practice.
First I thought that it might be some error in ClickUtils.copyObjectXXX, but they work as expected.

The problem:
"Java property representation of the given label".

In many forms, there are always 2 or 3 fields that need other label than the equivalent DAO naming,
but only for the Labels.
Of course, one could do a setName('correct_DAO_name'), but that would
mean to know and always to care about small deviations in label naming, or to call it
for all fields, but any solution requires more code, or a greater source of errors.
And I haven't tested it in the context of I18N where the labels have different names depending on
the language - I suppose in this case, most of the mapping will be broken.

Considering that 'programming by conventions' simplify the work allot, I saw that in my code and
that from my team we always have something like:
--------
EmailField emailField = new EmailField("E-Mail");
// and even if using I18N the object name would be the same
EmailField emailField = new EmailField(getMessage("page.register.label.email"));
--------
So if one ignores the 'Field' suffix, than the name of the object is a much better candidate for
the HTML name attribute than the Label text - in all cases in our code respects the DAO naming.

One idea would be to build the Field name automatically based on the object name (minus the 'Field'
suffix if it has one).
Of course, in the Filed constructor the name of the object is not available, but before adding the
object to the form, or just before leaving the onInit() the object name is there.
So maybe something like: ClickUtils.normalizeFieldNames(form); called just before leaving onInit()
would do it. It could change only those names where a deviation is found.

Do you have any other ideas on how to solve this problem?
IMHO Form<->DAO mapping is too productive to give it up, still my example is a real
one and in practice it doesn't work what we have now.

Thanks in advance,

Ahmed.



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Click-development mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/click-development
Reply | Threaded
Open this post in threaded view
|

Re: Field naming blows Form<->DAO mapping in practice.

Malcolm Edgar-2
Hi Ahmed,

I acknowledge that having to set the Field name to the that of the DAO's
property name is a bit laborious.  As you described, the current release
requires you to:

------------

  EmailField emailField = new EmailField("E-mail");
  emailField.setName("email");

------------

What I was hoping to get into release 0.11 was overloaded constructors,
but ran out of time, was:

------------

  EmailField emailField = new EmailField("email", "E-mail");

  EmailField emailField = new EmailField("email", getMessage("page..."));

------------

What you elluded to is quite interesting, and touches on some ideas that I
discussed briefly with Phil Barnes and Andrus Adamchik last week.

I started writing this up on the Wiki to hoping to continue this discussion in
public.

   http://www.sunvolt.com/confluence/display/CLK/ActiveRecord

This intro was as far as I got, until I realised I couldn't edit the Wiki page.
Phil is currently working on this.

Anyway the discussion basically was wouldn't it be great if you could:

-------------

public class NewCustomerPage extends Page {

    ActiveForm form = new ActiveForm("form");

    public void onInit() {
        addControl(form);
        ..
    }

    public void onGet() {      
        form.setActiveRecord(new Customer());
    }

    public void onPost() {
        if (form.isValid()) {
            Customer customer = (Customer) form.getActiveRecord();
            customer.save();
            ..
        }
        ..
    }
}

-------------

In this example the Form automatically builds itself by examining the business
object its given. It figures out what Field controls to use and how they should
be validated.

Now one of the problems with J2EE is that Java objects don't provide enough meta
data about themselves to do this. For example given a User class which maps to
the USER table:

create table USER (
   USERNAME VARCHAR(12) NOT NULL,
   PASSWORD VARCHAR(12) NOT NULL

);

In Java can't determine that the User.getPassword() property can't be null and
can't be any longer that 12 characters.

However this information is critical, and in many J2EE web apps it has to
replicated everywhere (persistence mapping files, Business tier validation, web
validation and rendering).

The persistence layer is where this missing information should come from.

Andrus,  who developed the Cayenne ORM framework, is using Cayenne with Click.
Cayenne provides this metadata information.

I was using Hibernate and from what I can see it doesn't provide this
information. I would need to write something to crawl over the Hibernate mapping
files to get this information out. If I am wrong on this I would love to know.

Now what would be good if there was a some sort of persistence metadata adaptor
which could enable Forms to get enough information about business objects to do
something intellegent with them.

This is where the discussion left off.

At the same time I have been looking at the Ruby on Rails (RoR) framework after
Phils recent foray. Well what can I say, RoR looks very impressive.

What I was particularly taken with was the design concept of "Opionated
Software". Meaning the framework design works this specified way, and if you
follow these conventions it can make all sorts of assumptions on how things
work. Thus relieving you of much of the laborious Schema <-> DAO <-> Valiation
work.

This is a very different approach to J2EE where flexibility is King, or  "I can
do anything you want, so long as you tell me exactly what you want... sorry you
were speaking to our Persistence Operator you will have to tell me again... Now
would you like me to I forward your call to our Business Operator?"

Click has some opinionated bits, with the Page class <-> template mapping,
but nothing like RoR.

With RoR I was really impressed by ActiveRecord package. RoR uses ActiveRecord
to enable validation of data all the way up into the web tier, so updating the
schema and ActiveRecord will be automatically reflected in web controller and
view.

I have started working on a Java interpretation of this ActiveRecord concept.


This might not answer your original question, but its food for thought.

I could look at getting a multiple constructor release out sooner if this
would help.

  EmailField emailField = new EmailField("email", "E-mail");

regars Malcolm Edgar



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Click-development mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/click-development
Reply | Threaded
Open this post in threaded view
|

Re: Field naming blows Form<->DAO mapping in practice.

Ahmed Mohombe
Hi,

this is getting longer :).

> What I was hoping to get into release 0.11 was overloaded constructors,
> but ran out of time, was:
I wanted to make the constructor matrix, but I *still can't* edit in Confluence.
That's why I said not to close the tickets.
And that's why I had the request that users(registered) CAN reopen tickets,
cause otherwise they're ignored for weeks (btw. for this was another ticket :) ).

> What you elluded to is quite interesting, and touches on some ideas that I
> discussed briefly with Phil Barnes and Andrus Adamchik last week.
>
> I started writing this up on the Wiki to hoping to continue this discussion in
> public.
>
>    http://www.sunvolt.com/confluence/display/CLK/ActiveRecord

> This intro was as far as I got, until I realised I couldn't edit the Wiki page.
> Phil is currently working on this.
Well, I can't edit that page either. In fact I can't edit any page from Click space.
The space is wrongly configured, or there's an error in your Confluence version(since
Phil said that he was able to edit with a test users without admin rights).

I made a new space (yes, that right exists now, but it shouldn't for users), just
to test, and there of course I have the rights.
Anyway, if you see right, there's no user contribution in the wiki (but on the forum
there were many users and ideas) - I suppose you know why is that so now :).
If I see right, now I'm the last user how is still crying "it's still not working" :), cause
all the others gave up :(.

Regarding your discussion, why aren't you making it here on this newsgroup? At the moment
there's almost no activity and it looks pretty abandoned :).

> public class NewCustomerPage extends Page {
>
>     ActiveForm form = new ActiveForm("form");
>
>     public void onInit() {
>         addControl(form);
>         ..
>     }
>
>     public void onGet() {      
>         form.setActiveRecord(new Customer());
>     }
>
>     public void onPost() {
>         if (form.isValid()) {
>             Customer customer = (Customer) form.getActiveRecord();
>             customer.save();
>             ..
>         }
>         ..
>     }
> }
I made almost the same, but without Click changes:
public class CustomerPage extends DAOPage {
...
}
I'm doing the entire magic in a base DAOPage (something like the Border page in your
example).

> In this example the Form automatically builds itself by examining the business
> object its given. It figures out what Field controls to use and how they should
> be validated.
Exactly this is what I always wanted - hence my requests in this direction :).
And I did this directly with JDBC (using jakarta-commons-DBUtils and pure JDBC metadata) +
cache-ing for simple/smaller applications.
I also tested with an ORM for more complicated examples. In this case I used
business delegate instead of direct DAO in ClickPages, since the scenarios
were more complicated.

> Now one of the problems with J2EE is that Java objects don't provide enough meta
> data about themselves to do this. For example given a User class which maps to
> the USER table:  
> create table USER (
>    USERNAME VARCHAR(12) NOT NULL,
>    PASSWORD VARCHAR(12) NOT NULL
>
> );
> In Java can't determine that the User.getPassword() property can't be null and
> can't be any longer that 12 characters.
Well this information exists and with JDBC can be obtained very easily. Every
DB Query tool can do this in a nice way (DBVisualizer, SquirrelSQL, Abeille, etc.)
I'm also using this since ages: generating Struts validations, forms, actions,
JSPs, CRUD, etc. Also did this before Struts was the "new kid on the block" with
simple JSPs and servlets.

What information can't be extracted from the DB is that the "PASSWORD" should
be of type "password" in the GUI :). That's why conventions are important, to
find out such things :). But conventions should be configurable too :).

> The persistence layer is where this missing information should come from.
No, IMHO it should come directly from the DB. The persistence the ORM should
do the right way it's job in persisting, and all the other possible 'inference sources'
should be used as directly as possible to their source, to avoid complications and possible errors.

> Andrus,  who developed the Cayenne ORM framework, is using Cayenne with Click.
> Cayenne provides this metadata information.
That's nice :). I thought however that he is using Tapestry - and most of the
Tapestry users think that too :).
I know that Cayenne is very impressive, and it's trying to copy WebObjects(btw. still
my TOP 1 tool, till JetBrains Fabrique will be ready), but I don't think it's
the job of the ORM to deal with such things. I think Cayenne Modeler should
be more intelligent and handle such things :).

> I was using Hibernate and from what I can see it doesn't provide this
> information. I would need to write something to crawl over the Hibernate mapping
> files to get this information out. If I am wrong on this I would love to know.
IMHO hibernate WAS just doing fine, but now is just too heavyweight - started to look like JBoss :D.
Anyway, you can obtain that information directly from the DB,
since it's no 'data access', but metadata access, so it's not a problem to bypass the ORM.

> Now what would be good if there was a some sort of persistence metadata adaptor
> which could enable Forms to get enough information about business objects to do
> something intellegent with them.
To be sincere, I dislike the concept of 'adaptors' or everythinkg that complicates the framework.
This metadata is not changing at runtime, so it shouldn't be in a framework, but
in a tool that helps build the forms or helps the framework.

Frameworks should remain simple for use, but also lightweight and small footprinted.
All the other jobs that mainly do not change at runtime, should be done by tools.
Of course, frameworks should be usable without tools too, but the idea of tools is
to speed up the work.
My 'ActiveRecord' example, it was in fact 'InnactiveRecord' :), cause that information
was 'inserted' at design time, not at runtime :).

> This is where the discussion left off.
Well, as I said, I think it's the worng direction to complicate frameworks.
I like Click cause it's simple (not just to use it but also the framework itself),
and it's something users can understand. I wouldn't like if starts to became more
complicated.
IMHO a Click-Tools project cold be created (as a separate CVS repository in the
current SF project) for such things.

> At the same time I have been looking at the Ruby on Rails (RoR) framework after
> Phils recent foray. Well what can I say, RoR looks very impressive.
It is impressive, but it's pretty limited to DDD, and XP work scenarios(regarding
the magic :) ). In practice, it's not very often that one has such 'ideal' conditions.
Of course, there should be such conditions, but we as developers can't really influence
or change the managers and the customers :).

I already used RoR in 2 smaller real projects, and it's not that 'impressive' how it looks
when one starts to learn it. When you deal with 'reality' and not 'ideal
project conditions', RoR it's no magic anymore, and no 10x improvement. Said that it's
no improvement at all.I know, many RoR fans would jump on this but this is my experience,
and I was very excited too about RoR first, but I also used it in practice, not just
writing about it and making small shiny movies.
In fact, for real projects Java is still the best, and the good practices, patterns,
specifications(IMHO JCRs are great) and an intelligent IDE like IntelliJ help much more
under real conditions.

The only drawback of Java based J2EE projects is that there's no fast startup help,
nor a JCR that would improve it.
Some projects like:
- appfuse.dev.java.net
- appfusegenerator.dev.java.net
- conductor.dev.java.net
- e-gen.dev.java.net
- trails.dev.java.net
- http://sourceforge.net/projects/jag
- there are many more (even commercial).
try to fill this gap, but not in a very intelligent manner, but still very practical
in their niche. They are however a good source of inspiration for better and
more intelligent tools (that help simple frameworks).

> What I was particularly taken with was the design concept of "Opionated
> Software". Meaning the framework design works this specified way, and if you
> follow these conventions it can make all sorts of assumptions on how things
> work.
Most users do the same with Struts too :), just that the Struts does nothing to help
the users if they respect conventions :). In this case, tools should do the work, and they do:
Just look at JAG, or other generation tools like AppFuse/AppGen or AppFuseGenerator.
There are many other, not to mention the many 'in house' tools. Of course, these tools
are missing the 'detail touch' like modern IDEs, but even so they are a great productivity boost.

> Click has some opinionated bits, with the Page class <-> template mapping,
> but nothing like RoR.
RoR has nice ideas (btw. nothing is new, and already existed in many 'in house'
projects), but I wouldn't like just to copy them and transform Click in some
sort of DDD only framework Java clone of the RoR.
Of course, we could find other 'simplification' areas, in Click, but not
by complicating too much the framework and not by just coping RoR :).

> With RoR I was really impressed by ActiveRecord package. RoR uses ActiveRecord
> to enable validation of data all the way up into the web tier, so updating the
> schema and ActiveRecord will be automatically reflected in web controller and
> view.
Reflection might be interesting, but IMHO, it's not always needed, since that information
does not change at runtime. It's enough if it's generated/created at build time.
Of course, since Ruby is interpreted and dynamic, it's simpler to reflect, but for Java it's not.
So for Java it's better to generate what's not changing and can be separated in
'generated packages' (not to be edited by hand cause it might be regenerated).

In case of Click automapping, it's good that it's not generated, but 'reflected' at
runtime. One could generate with an ANT task the 'detailed' click.xml, but
this would be a limitation, cause pages might change at runtime (just think of CMSes).

> I have started working on a Java interpretation of this ActiveRecord concept.
Look at Trails blog:
http://www.jroller.com/page/ccnelson
There's a blog article about ActiveRecord stating that it's not required to implement
such thing when you have Hibernate. It has interesting points.

> This might not answer your original question, but its food for thought.
It is :). After all, the purpose of computers is to simplify life, not
to make it more complicated :D.

> I could look at getting a multiple constructor release out sooner if this
> would help.
Of course it would help. How should not help to reduce the code with 80%
for most of the form construction code ? :).

Thanks in advance,

Ahmed.



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Click-development mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/click-development
Reply | Threaded
Open this post in threaded view
|

Re: Re: Field naming blows Form<->DAO mapping in practice.

pbarnes
On 9/21/05, Ahmed Mohombe <[hidden email]> wrote:
Hi,

this is getting longer :).

This is indeed going to be  fun (aka long)!

> What I was hoping to get into release 0.11 was overloaded constructors,
> but ran out of time, was:
I wanted to make the constructor matrix, but I *still can't* edit in Confluence.
That's why I said not to close the tickets.
And that's why I had the request that users(registered) CAN reopen tickets,
cause otherwise they're ignored for weeks (btw. for this was another ticket :) ).

[snip]
> This intro was as far as I got, until I realised I couldn't edit the Wiki page.
> Phil is currently working on this.
Well, I can't edit that page either. In fact I can't edit any page from Click space.
The space is wrongly configured, or there's an error in your Confluence version(since
Phil said that he was able to edit with a test users without admin rights).

I've temporarily fixed this by allowing anonymous page creation.  I say temporary, as I'd like to require user registration for page creation, to prevent anonymous spam (as I've seen so many wikis devolve into uselessness because of).

Regarding your discussion, why aren't you making it here on this newsgroup? At the moment
there's almost no activity and it looks pretty abandoned :).

It popped up out of a completely unrelated and non-Click relevant discussion -- as you see below, Ruby on Rails :) So it happened quite accidentally, and thus Malcolm posted it here now.

> Now one of the problems with J2EE is that Java objects don't provide enough meta
> data about themselves to do this. For example given a User class which maps to
> the USER table:
> create table USER (
>    USERNAME VARCHAR(12) NOT NULL,
>    PASSWORD VARCHAR(12) NOT NULL
>
> );
> In Java can't determine that the User.getPassword() property can't be null and
> can't be any longer that 12 characters.
Well this information exists and with JDBC can be obtained very easily. Every
DB Query tool can do this in a nice way (DBVisualizer, SquirrelSQL, Abeille, etc.)
I'm also using this since ages: generating Struts validations, forms, actions,
JSPs, CRUD, etc. Also did this before Struts was the "new kid on the block" with
simple JSPs and servlets.

A lot of this is database dependent and even moreso JDBC driver dependent.  While it's true that some information could be inferred (specifically: type, size, required), it would require testing against a number of databases and database drivers -- not for the feint of heart.  ;)

> The persistence layer is where this missing information should come from.
No, IMHO it should come directly from the DB. The persistence the ORM should
do the right way it's job in persisting, and all the other possible 'inference sources'
should be used as directly as possible to their source, to avoid complications and possible errors.

While it *should* come from the DB, this is competely impractical, unless you only support a small subset of databases.  As a Java framework, it would be far more practical to build an API and adapter against a few ORM applications with hooks (via API) for others to implement.

> I was using Hibernate and from what I can see it doesn't provide this
> information. I would need to write something to crawl over the Hibernate mapping
> files to get this information out. If I am wrong on this I would love to know.
IMHO hibernate WAS just doing fine, but now is just too heavyweight - started to look like JBoss :D.

Hmm, I'm curious to know what exactly Hibernate added that was heavyweight (that was not optional).

Anyway, you can obtain that information directly from the DB,
since it's no 'data access', but metadata access, so it's not a problem to bypass the ORM.

But if you're using an ORM, this would require separate database calls, potentially separate mappings (what Model object goes with what Table), etc.

> Now what would be good if there was a some sort of persistence metadata adaptor
> which could enable Forms to get enough information about business objects to do
> something intellegent with them.
To be sincere, I dislike the concept of 'adaptors' or everythinkg that complicates the framework.
This metadata is not changing at runtime, so it shouldn't be in a framework, but
in a tool that helps build the forms or helps the framework.

I disagree.  I want a framework to make my job easier by doing more with less (i.e. what I want in fewer lines of code, without sacrificing maintainability).  I don't care to have a tool build anything for me, as it's almost never what I want, and as soon as I customize it, I break whatever advantage the tool was providing.  As for Adapters, I dislike complex adapters, but simple adapters can be helpful (see Hibernate's 2nd level cache API for instance).

Frameworks should remain simple for use, but also lightweight and small footprinted.

Simple and powerful are usually polar opposites, so there's always a tradeoff.  Lightweight I agree with (the coding equivalent of laissez faire).  A small footprint is less of a concern, as long as it's lightweight and productive.

All the other jobs that mainly do not change at runtime, should be done by tools.
Of course, frameworks should be usable without tools too, but the idea of tools is
to speed up the work.

I'm guessing I'm misunderstanding what you mean by 'tools'.  Are you talking one time generation?  Round-tripping?  Configurable creation (i.e. XDoclet)?

> This is where the discussion left off.
Well, as I said, I think it's the worng direction to complicate frameworks.
I like Click cause it's simple (not just to use it but also the framework itself),
and it's something users can understand. I wouldn't like if starts to became more
complicated.

I would assume that Malcolm is implying optional (but integrated) behavior, ala Spring or even Ruby on Rails.

> At the same time I have been looking at the Ruby on Rails (RoR) framework after
> Phils recent foray. Well what can I say, RoR looks very impressive.
It is impressive, but it's pretty limited to DDD, and XP work scenarios(regarding
the magic :) ). In practice, it's not very often that one has such 'ideal' conditions.
Of course, there should be such conditions, but we as developers can't really influence
or change the managers and the customers :).

This is purely your experience with it, not a valid generalization to all people everywhere.  Consultants especially are in a position to recommend and influence both managers and customers, and I've been at several companies in which the client actually empowers the employees to help set technological direction.

I already used RoR in 2 smaller real projects, and it's not that 'impressive' how it looks
when one starts to learn it. When you deal with 'reality' and not 'ideal
project conditions', RoR it's no magic anymore, and no 10x improvement.

If you're trying to fit RoR onto an existing project or schema, you're trying to do something that the framework wasn't intended to do.  That wouldn't be any different than to try to make Hibernate read and persist to an object-oriented or XML database -- it can probably be done, but definitely not trivially.

Said that it's
no improvement at all.I know, many RoR fans would jump on this but this is my experience,
and I was very excited too about RoR first, but I also used it in practice, not just
writing about it and making small shiny movies.

As have I and my experience is the opposite.  My expectation is that you're trying to make it do something it's not designed to do.  RoR is about building database drive web applications from scratch.  While it can be made to do otherwise, it simply becomes another web application framework.

In fact, for real projects Java is still the best, and the good practices, patterns,
specifications(IMHO JCRs are great) and an intelligent IDE like IntelliJ help much more
under real conditions.

If you're talking maintainability, I'd probably agree -- there's just a vast wealth of knowledge and applications available to support Java development.  If you're starting a brand new (web-based) project, then things aren't so clear cut.

The only drawback of Java based J2EE projects is that there's no fast startup help,

I assume you mean for web applications, not the entire stack, but still, I disagree.  There are a multitude of non-productive drawbacks.  Limited class-reloading (hotswap).  Slow, monolithic container requirements.  Limited web-tier integration capabilities.  Limited cross-cutting concern options.  Overly complex standards (JSF, EJB 1&2).  Vendor driven JCP EG's.  etc.  Are some of these being addressed?  Sure, but they're definitely not here today.

> What I was particularly taken with was the design concept of "Opionated
> Software". Meaning the framework design works this specified way, and if you
> follow these conventions it can make all sorts of assumptions on how things
> work.
Most users do the same with Struts too :), just that the Struts does nothing to help
the users if they respect conventions :).

Struts tries to force 'convetion' through explicit coding and configuration practices.  Unfortunately, this design choice also "hemmed" Struts into a corner, where it can now only go so far forward and still be backward compatible.

> Click has some opinionated bits, with the Page class <-> template mapping,
> but nothing like RoR.
RoR has nice ideas (btw. nothing is new, and already existed in many 'in house'
projects), but I wouldn't like just to copy them and transform Click in some
sort of DDD only framework Java clone of the RoR.

True, nothing is particularly new, but noone/nothing has put it all together so cleanly and easily either.  ;)  WebObjects is close, I suppose, but it's still nowhere near as trivial to develop with.  It's probably not practical nor possible to copy anything much from Rails, due to Ruby's dynamic nature -- just use the ideas as design/discussion points, as we're doing right now.  :)

> With RoR I was really impressed by ActiveRecord package. RoR uses ActiveRecord
> to enable validation of data all the way up into the web tier, so updating the
> schema and ActiveRecord will be automatically reflected in web controller and
> view.
Reflection might be interesting, but IMHO, it's not always needed, since that information
does not change at runtime. It's enough if it's generated/created at build time.
Of course, since Ruby is interpreted and dynamic, it's simpler to reflect, but for Java it's not.
So for Java it's better to generate what's not changing and can be separated in
'generated packages' (not to be edited by hand cause it might be regenerated).

I'm very much an OPPONENT of the generation/regeneration cycle, as rarely generates what I need or want.  I'd rather change something, hotwap, and see my changes, rather than change, regenerate, recompile, redeploy, and test only to find I made a typo and have to repeat the whole process.  This is where Java and current Java frameworks have it all wrong.

> I have started working on a Java interpretation of this ActiveRecord concept.
Look at Trails blog:
http://www.jroller.com/page/ccnelson
There's a blog article about ActiveRecord stating that it's not required to implement
such thing when you have Hibernate. It has interesting points.

Specifically EJB3, with annotations (and it so happens that Hibernate 3 supports those annotations).  Completely useless for anyone using Hibernate 2 or some non EJB3 persistence framework.  ;)  And it's still EJB from the standpoint that it requires some kind of container to run in/with.

After all, the purpose of computers is to simplify life, not
to make it more complicated :D.

Sometimes, I wonder the opposite.... :D

Phil..