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:[EMAIL PROTECTED] Sent: Friday, June 23, 2006 10:12 AM To: [email protected] Subject: Re: External framework tie-ins? On Fri, 23 Jun 2006 10:00:15 -0400, Gentry, Michael (Contractor) <[EMAIL PROTECTED]> 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 @For/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
