Nando, Thanks. That is all very clear. The only part I don't quite follow is the display page. If I have a page that displays the details for a single publication, you favor gateway over a bean simply because there is no editing taking place?
I just figured a bean would be great when dealing with any page that requires editing/viewing/deleting ONE of an item. Thanks for all the advices. ...................... Ben Nadel Web Developer Nylon Technology 6 West 14th Street New York, NY 10011 212.691.1134 212.691.3477 fax www.nylontechnology.com "Vote for Pedro" -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nando Sent: Wednesday, December 14, 2005 3:15 PM To: [email protected] Subject: RE: [CFCDev] Object relations, getting, setting, and validation Oh My! Ben, If you're just display data on a detail page, all you probably need is a gateway. A bean is useful when you're editing data, but if all your doing is displaying data, a gateway works just fine. So i'm saying that you can use just a single gateway method, say publicationGateway.findPublication(). And within that method, you use the necessary joins to fetch the author and category stuff. When you're editing the publication, you probably don't need to compose the author and category stuff into the publication bean. Again, if all you're doing is displaying a dropdown list of categories for a user to choose from, a gateway method works fine. Your publication might have a property "category" or "categoryID", but unless you have a specific need for the user to edit categories within publications, you probably don't need a bean composed within another bean, or even to compose a gateway within Publication. In other words, if you have a form for editing categories, you're probably doing that separately. Imagine a link to a section of your app - Edit Categories. Click on the link, and a list of categories appears (via CategoryGateway). Click on a category, and a form loads (via CategoryBean). In those moments, there is no need for a Publication bean, even tho' Publications have Categories and Categories have Publications. So what i'm saying is that when implementing your model, only use composition when you really need it. Of course, you CAN instantiate a Category, instantiate an array of Publication objects within Category, instantiate an array of Author objects within Publication, and call category.getPublication().getAuthor() when you are editing a particular author, but unless you have a very practical reason for doing so (sometimes that happens!), it's clearer and simplier just to instantiate a single Author bean when editing an author, even if from a conceptual level a Publication always has one or more Authors. I'm trying to say something with the above examples that may not be exactly what you were planning to do, of course. Just demonstrating how the conceptual perspective can be very different from what you actually implement, and suggesting that you can / should keep the implementation as simple and transparent as possible. Nando.getSomeSleep('buona serata') ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
