I'm not sure things needed to be added in, but perhaps some better
documentation. Such as with Tapestry, document how you can use a
DataSqueezer (and point to Tapestry wiki page -- or wherever the
squeezer is). Or use the hash code approach I was talking about if your
application shouldn't be exposing database information (keys/tables/etc)
to the client. These seem more of a best practice type of thing than
adding more into Cayenne (when it can be avoided). Also, with T4, you
have to be careful with..or/etc because if you are in a FORM, it wants
to serialize your data objects to the HTML page it generates. When the
user submits the form, it deserializes your data objects, but then they
are detached from the data context, which is bad. The above two
practices prevent the serialization (or re-attach conveniently).
/dev/mrg
-----Original Message-----
From: Kevin Menard [mailto:kmenar..ervprise.com]
Sent: Friday, June 23, 2006 9:07 AM
To: cayenne-de..ncubator.apache.org
Subject: External framework tie-ins?
Hey all,
The recent thread with Michael re: Tapestry and even the one on the
users
list not too long ago about HiveMind & Cayenne got me thinking a little.
How do you guys feel about having framework extension package in
Cayenne?
I realize there's a push not to include what can be perceived as bloat,
but realistically, a few extra classes here and there aren't going to
make
a huge difference. Currently, we rely on the external frameworks to add
support for Cayenne. If they don't add it, then we sorta just linger.
E.g., Spring didn't add Cayenne support, so Spring-Cayenne integration
went into an external lib that hardly anyone uses.
Cayenne is pretty simple to integrate with most frameworks, so I think
we've ignored the integration aspect thus far. But everyone that wants
to
tie in with Tapestry, for example, has to jump through the same (few)
hoops. I suppose that could be one argument for using Click, which
seems
to work well with Cayenne out of the box, but we should try to maximize
exposure.
The presence of an external contrib lib could be argued for, but what
I'm
aiming to do is cut down on the amount of time to tie in with whatever
other frameworks. I also want something that is fairly well supported
and
maintained.
-- Kevin
This archive was generated by hypermail 2.0.0 : Fri Jun 23 2006 - 10:00:41 EDT