I think when you just need some id's and descriptions for a drop-down list on a
form then a query is a great thing to have and all you need. Things are
unlikely to change so there's no risk.
It's only when I have more to display (ie a list of users with names, email,
thumbnail and different css depending on the user's role) that I consider an
Iterator bean loaded with the query.
That way I protect myself more from changes and there's less duplication.
Rather than the view code probably violating DRY and looking like this:
<cfoutput query="variables.qGetUsers">
<!--- build the fullname --->
<cfset variables.fullname = "" />
<cfif Len(trim(variables.qGetUsers.title))>
<cfset variables.fullname = variables.qGetUsers.title />
</cfif>
<!--- firstname mandatory so we should have it --->
<cfset variables.fullname = variables.fullname & " " &
variables.qGetUsers.firstname />
<cfif Len(trim(variables.qGetUsers.middlename))>
<cfset variables.fullname = variables.fullname & " " &
variables.qGetUsers.middlename />
</cfif>
<!--- lastname mandatory so we should have it --->
<cfset variables.fullname = variables.fullname & " " &
variables.qGetUsers.lastname />
<!--- end: build the fullname --->
<!--- get age --->
<cfif isDate(variables.qGetUsers.dateOfBirth)>
<cfset variables.age =
datediff("yyyy",variables.qGetUsers.dateOfBirth,now()) />
<cfelse>
<cfset variables.age = "-" />
</cfif>
<p>#variables.fullname# <cfif isValid("integer",variables.age)> is aged
#variables.age#<cfelse>hasn't specified a date of birth</cfif></p>
</cfoutput>
encapsulating the query and business logic in an Iterator 'bean' makes the view
look more like this:
<cfloop condition="#variables.User.hasNext()#">
<cfset variables.User.next() />
<p>#variables.User.getFullname()# <cfif variables.User.hasAge()>is aged
#variables.User.getAge()#<cfelse>hasn't specified a date of birth</cfif></p>
</cfloop>
And I really like my View code looking like this (and hopefully so will the
front-end developer that has to edit the Views)
Alan
www.alanlivie.com
________________________________
From: Barry Beattie <[email protected]>
To: [email protected]
Sent: Tuesday, January 13, 2009 8:31:16 AM
Subject: [CFCDEV] Re: Analysis and Design process
"It returns a coldfusion query object, when it should really be a
collection of objects."
in an ideal world, sure. but sometimes it's complete overkill. and if
it got to that stage, I'd rather have a Collection object that was
really hiding a query inside it, handing me back single objects when -
and only when - I need them, like getting a sub-collection (really a
QofQ)
IMHO the humble query object is a much maligned and overlooked beasty.
On Fri, Jan 9, 2009 at 8:36 PM, John Whish <[email protected]> wrote:
> Now you're preaching to the converted :) I decided that I'd rather create
> transient objects then bodge it. The Transfer get is a classic example of
> this. It returns a coldfusion query object, when it should really be a
> collection of objects. I did play around with using Peter Bell's IBO with it
> (which works well), but I was concious that it was a work-around. As you say
> CF is getting faster and so is hardware so I'd prefer to go down that route
> (especially with the new Object proxies feature of transfer)
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"CFCDev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/cfcdev?hl=en
-~----------~----~----~----~------~----~------~--~---
