I really haven't looked at the JPA stuff too much. Is the prePersist
firing on newObject() intended to initialize the object? If new
callbacks were introduced, that would certainly be an incompatible
change with the JPA specification, then. If you implemented something
in Cayenne and then had to drop it into a different implementation, it
wouldn't work. (Unless JPA wasn't intended to work that way in the
first place.) What is the real motivation for JPA compliance?
(Marketing/promotion/adoption purposes, etc?)
As for Tapestry ... they have had a long history of not being backward
compatible. It is actually a huge point of concern where I'm at where
they have Tapestry 4.0.x and 4.1.x applications (and 4.1 isn't even
compatible with 4.0), plus a ton of WebObjects. The question here is
where to go next. Tapestry 5 or JSF (a "standard") or something else.
In some ways the Tapestry turmoil hurts adoption of Tapestry and
continuing use where Tapestry is already being used. I'm not saying
good and meaningful changes, even if incompatible, shouldn't be made,
but it always has an impact which should be considered.
OK, sorry for rambling ... back to work. :-)
mrg
On Wed, Mar 18, 2009 at 6:57 AM, Andrus Adamchik <andru..bjectstyle.org> wrote:
> I agree, it doesn't technically prevent us from adding more... What I feel
> bad about is the design falling apart. We already have validateFor..., JPA
> callbacks, and now we'll have a third kind :-/ This turns Cayenne into
> Perl... Almost envy the Tapestry people for pulling the plug on backwards
> compatibility in the sake of consistency of the user-facing components.
>
> Andrus
This archive was generated by hypermail 2.0.0 : Wed Mar 18 2009 - 10:17:36 EDT