I still think putting such things on the wiki could be quite useful. We
can have Tapestry/Cayenne documentation and source code attached as
files for download, so someone won't need to re-write things, just get
the code. Just my opinion, though. Anyone else have thoughts on the
matter?
Thanks,
/dev/mrg
-----Original Message-----
From: Kevin Menard [mailto:kmenar..ervprise.com]
Sent: Friday, June 23, 2006 10:12 AM
To: cayenne-de..ncubator.apache.org
Subject: Re: External framework tie-ins?
On Fri, 23 Jun 2006 10:00:15 -0400, Gentry, Michael (Contractor)
<michael_gentr..anniemae.com> wrote:
> 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).
This is exactly what I was saying is part of the existing problem.
Everyone now has to jump through the same hoops, regardless of
documentation. Whereas, for example, we could have a
TapestryCayenneDataObject or something that adds some of this stuff
right
in. Perhaps the Cayenne data squeezer could be absorbed as well. Maybe
even add in that DataContextFactory I posted for interacting with
HiveMind.
Now, when I want to start up a Tapestry project, everything I need is
already there. I really don't have to write the same code that many
others have written before me. The documentation can then tell me how
to
use the API rather than telling me how to write my own.
> 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).
Perhaps a caveat in documentation is the best approach. It just strikes
me that there has to be a better way that'll prevent the issue from
happening in the first place.
-- Kevin
This archive was generated by hypermail 2.0.0 : Mon Jun 26 2006 - 10:22:53 EDT