Adam Cameron wrote:
Hi John.
Just looking at your code, and have a couple of questions:
1) What's the perceived benefit of using the displayname attribute of
<cfcomponent>? I've never understood why people bother with it.
The object represents a data recordset. The attributes are the data
columns. There are no addtional attributes in my CFC, only the data
column names are passed to the attributes scope.
2) returntype="any"? Shouldn't it be "QueryIterator"?
Likely... thanks. (also changing the name to all small for linux safety.)
3) Heaps of people do this... lines 17-27. Any reason to have the VAR and
RETURN statements outside the script block?
No... as long as you put the var first it will work. I just tend to do
that routine so it doesn't get messed up. It's my rut routine for doing
it right.
4) Not sure of the reasoning behind the return values of moveFirst() and
moveLast(). They're move functions, not "and check if I was already there,
too, pls" functions. But equally, I can see where you're coming from.
I plan later to add features for deleting records. If someone deletes
all their records it would be good to toss a fail result because you
cannot move to a non-existing record. It's just preparing for a later
version.
5) I'd be inclined to throw an out-of-bounds error in movePosition() if an
invalid position was specified.
Good... toss me a snippet. I would be glad to build that in. (I was
thinking just move to last record... but should also have logic to check
for valid record number... being a rounded integer and between one and
the last record... but haven't done that yet.)
6) I think someone else mentioned this.
a) In setAttributes(), I'd put them in a substruct, not straight
into THIS.
Right... that is a style. I have voted on the CF wish list for
"protected attributes". Right now this is the way I set externally
visible attributes that don't modify internal variables the CFC uses.
They are not "protected" but the internal workings of my CFC are safe. I
create a (variables.attributes) structure to hold the attributes I
typically expose in this scope. Most of my CFCs that do that function
simply duplicate that structure out to the this scope.
b) I'd also question putting them in even a substruct of THIS. Do
you want the calling code to be able to change those values? I wouldn't.
Changing those values won't cause the CFC to fail... but there is an
issue. Even PHP has a protected scope for this... in fact so does JAVA
and Microsoft solutions. This is one strong wish list issue that we need
in the next upgrade of CF. If we had a protected scope you guys wouldn't
be afraid to do things this way. The process is logical... it's just not
protected.
c) I'd use <cfset this[columnName] =
variables.query[columnName][variables.currentRow]>. Removes the need for
the try/catch.
Done... old habbits. Been at it since CF 4.0 and sometimes the get back
in my code. Thanks.
7) With 6c in mind, I'd add a getAttributes() method (or some other
similarly-intented mechanism to get the attributes out).
Respectfully the inner workings are safe. We both agree for now the
inner code of the CFC should never address the object attributes from a
logic perspective. In other words the functions should never reference
the attributes to perform logic. In fact the way I do it... the
attributes are just a way of exposing internal settings of the object.
Currently the attributes cannot be protected and should rarely and
mostly never be used to pass information into a CFC. Yet... it is a way
to get information out of a CFC. When you do a CFDump for example you
can see all the attributes. It does serve you well for debugging and
programming. (Just a style issue... again... go to wish list and vote
for change if they don't add it to the next beta.)
I've got a collection component of my own, and it's much the same as what
you're doing here, except I'm hijacking the method names of the recordset
interface CF query objects use, so just first(), last(), previous(), etc.
I'm still experimenting with it at present, but I'm hoping to get it working
with collections of any sort of object (with phase two being collections of
any sort of objectS, if you see the subtle difference). All these traversal
methods are in the base component, and then situation-specific collections
override the base class' methods for cloning, sorting, etc.
Interesting stuff.
Thanks and good luck with the code for the structure iterator CFC. I see
that is possible... you could just check for object type. I am thinking
in general that seperate objects with like functions would be more
ideal. Haven't seen your work though... so don't divert if you see
something that I don't for sure.
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]
