Couple of things. You've duplicated a couple of values. I'm not sure I see
why. Specifically, columnList and recordCount are copies from the original
query. Since you already have a reference to the query, you can just get
that information directly from the query. If the query changes, your values
will change.
That leads me to the query. I probably wouldn't have duplicated (using the
duplicate() function) the query itself. I imagine it would add quite a bit
of overhead and you lose the ability to modify the query (add rows to it,
etc). Your method is safer, obviously. But I probably wouldn't have made
that trade off.
Also, I generally try not to manipulate instance variables in more than one
place. For instance (no pun intended), The methods moveFirst(), moveLast(),
moveNext(), and movePrevious() should all call movePosition(). At which
point, those methods don't need any local variables. That might help
performance, but I doubt it would be significant in most cases. Mostly, I
just find it easier to read. In the future, if you need to perform any other
work when the current row changes, you can do it in movePosition() and only
movePosition().
Others have noted that the use of the "this" scope could introduce issues. I
agree with them. Besides naming collisions, you take a performance hit in a
couple of areas. Specifically, you're performing dynamic evaluation
("this.#columnName#"), which can be slow and error prone. Also, you're
performing a whole lot of work which might never be done. I might loop
through a record set that contains 10 columns but only ever ask for 5 of
them.
Your "columnName" variable in the setAttributes() method is not var'ed or
placed in the "local" scope. Also in that function, I would use
getCurrentRow() instead of variables.currentRow. Again, I try not to spread
accessor methods around the object. It makes it easier to add error
handling, refactor and, in my opinion, read.
Anyway, I think this is a good idea. I've been looking to do something
similar in conjunction with a PagerContext object that I use for
previous/next search results. It uses a URL object which allows me to
programmatically change out values as I move from one record to the next:
<cfset detailsUrl = pagerContext.getDetailsUrl()>
<cfset detailsUrl.setParam("ID", ID)>
<a href="#detailsUrl.toUrl()#">click here for more info</a>
In my case, I need to abstract the query so that I can just as easily loop
over an array of objects as I can a record set. So, I would need both a
query and an array iterator with similar interfaces.
Ben Rogers
http://www.c4.net
v.508.240.0051
f.508.240.0057
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of John Farrar
> Sent: Wednesday, February 23, 2005 9:43 PM
> To: [email protected]
> Subject: Re: [CFCDev] query object CFC Beta
>
> Here it is... the guys on this list should be able to understand it's
> usage. (If anyone wants to help document... that would be great also.)
> This version is somewhat tested... but don't have a full QA on this, so
> let me know if you find any "fixes" or "enhancements".
>
> Thanks again,
>
> John Farrar
>
>
> ----------------------------------------------------------
> 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]
----------------------------------------------------------
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]
