In Tapestry, we use model objects as the data-buffer. If we're editing an entity, and something goes wrong, we can set an errorMessage property, "return this;", and expect the user to see the form still filled-out with what they'd just typed with an explanation of what went wrong.
If you're using Hibernate, however, I don't think this use-case is guaranteed; mainly because I'm currently dealing with cases where it isn't. What I mean by that: If something goes wrong in a Hibernate session, your entities are not guaranteed to be left in a stable state. i.e. they're not guaranteed to match their counterparts in the persistence layer. In my case, I'm trying to insert an object with some not-null properties left as null. Hibernate sets the primary key of my object (when it queries my Postgres sequence), but then fails on the actual entity-insert. An exception is thrown, but the primary key is left on my object. Since my Tapestry page is designed to handle both creating and updating this entity -- and since it does this by testing whether or not an object's primary key exists -- the user is told there was a problem, but as far as Tapestry is concerned, the user is now editing the entity, not creating it. I can hack it by explicitly setting the primary key to be null where I catch the Exception, but who knows what else Hibernate might be mutating without going through the source code. Am I crazy, or does this Hibernate practice mean that, everywhere we expect to be able to use an object even if something goes wrong in Hibernate, we have to clone our entity first or open ourselves up to potential problems? Are people doing this? Jim --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
