> I hope this description is helpful without being over complicated. :) No, that actually was fairly understandable to me.
I wasn't relating a "bean" to a query representing a single row in a table, but to a query that might return all users, etc. If I needed 5 different queries...saying one for email addresses containing "aol" and one for street addresses containing "Fox", etc....what would I do?...create a "bean" for each one of those queries and store them in memory? (Where's my picture? ;o) Rick > -----Original Message----- > From: S. Isaac Dealey [mailto:[EMAIL PROTECTED] > Sent: Monday, March 06, 2006 8:08 PM > To: CF-Talk > Subject: RE: OOP, why me? > > > > Sounds > > like you'd have to memorize all the users in your table > > to reference them...?!?!?! (Obviously not getting it...) > > > (I probably need a diagram... ;o) > > Heh... That's kind of a funny leap. :) > > This concept in particular isn't all that unusual or really even all > that complex... > > To make it dead simple, you know how to use a query -- the query has > rows and columns -- the columns have names and represent "properties" > of each record or row in the query. So if your query represents a > single person, the qPerson.FirstName variable represents the first > name of the person represented by the qPeople query. > > Now, all you have to do to turn that into objects is change the syntax > a little... You instantiate a Person CFC (maybe a bean) and you > populate it with data from a query (which can be done either inside > the person CFC or you can pass the person.cfc to a separate object > that will fetch data and populate its properties). > > When you're done populating your person.cfc, what you have is very > much like a structure which might have been created with a > QueryToStruct() function, and thus, Person.getFirstName() is now > equivalent of qPerson.FirstName ... > > What's the difference? Well you can do more with the CFC than you > could with the query. The CFC may contain methods that get data from > other tables to tell you for example what roles the user is associated > with in your security suite. (I'm not advocating that it have this, > I'm just saying it's an option.) With the query you have to create > another ad-hoc query to get this data - with the cfc any page that > needs it can simply reference a method of the instantiated Person, > i.e. Person.getRoles() would then replace an ad-hoc query that you > might otherwise have repeated in several places within your > application. > > So no, you wouln't have to know anything more about your individual > user records -- not any more than you do when using queries. > > I hope this description is helpful without being over complicated. :) > > s. isaac dealey 434.293.6201 > new epoch : isn't it time for a change? > > add features without fixtures with > the onTap open source framework > > http://www.fusiontap.com > http://coldfusion.sys-con.com/author/4806Dealey.htm > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:234365 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
