> This is so the code can consistently reference the object rather than
> jumping back in forward to query and object. This will be more the case
> if the CFC is enhanced with the ability to manipulate the object. (Say
> filtered, deleted and added or merged records)
I think I see what you're getting at. I think where we diverge is that I
wouldn't add the ability to manipulate the record set to this object. This
object is an iterator. It already has a clearly defined job. I would make a
separate object for query manipulation.
Actually, I probably wouldn't unless I was trying to solve a really specific
problem: the built in ColdFusion functions do an adequate job. But that's
not pertinent to the current conversation.
> Plan on building that function into a later version of the CFC. So...
> it's delayed rather than sacrificed.
Here's another example where we're on two different tracks. If I had two
objects, one for manipulating queries, the other for iterating over them,
then they'd both need references to the same query, not copies of it.
> If you are maintaining a variable external to the object for position
> you defeat a major reason for having the object.
I think you misunderstood what I was saying (or I conveyed it really
poorly). I would not store that variable externally. It would be stored as
it is in the code you posted.
Currently, you have no less than 5 functions which all do the same thing.
They set the variables.currentRow variable and call setAttributes(). You
already have one function, movePosition(), that does this in a generic
fashion. I would remove the aforementioned logic from moveFirst(),
moveLast(), moveNext(), and movePrevious(). I would make those functions
call movePosition().
> This is also why the
> attributes have the values of the query columns current record position.
> It's a self contained object that does some functions automatically. If
> you move to another row it automatically updates the counter and the
> attribute values. This is especially useful for newer programmers. It is
> also true that in your object handling code you would be using two
> functions... one to increase the external counter and another to set the
> position.
I'm not sure where you get the idea that there would be an external counter?
Neither Roland or I have suggested that. At least, I certainly didn't mean
to if I did. :)
> My object does this through one external call in the case of
> moving to first, previous, next or last records. It is also very
> readable for debug or enhancement purposes.
>
> NO... there are no naming collisions. The only attributes are the field
> names.
Actually, public functions are available in this this scope. So, yes, in
fact, you can run into name collisions. To test this, change the access
level to public on your setAttributes() method. Then, anywhere you call
setAttributes(), change it to this.setAttributes().
> When calling a method/function the call requires "()" so the code
> will not conflict.
But if you leave off the parenthesis you get a reference to the function.
Consequently, you'll overwrite your function reference. Add the following
function to your component to test this:
<cffunction name="causeNameCollision">
<cfset this.setAttributes = "">
</cffunction>
Create and initialize your iterator. Call causeNameCollision(). Then call a
function which will call setAttributes.
> The issues with naming issue are dependent on the
> field names. Heh... perhaps we should agree that there are more ideal
> names for column names in databases...
No, I think any implementation that causes you to rename columns in your
database is flawed. I don't think I've used those names in particular, but
for all I know, those names might make perfect sense in some context. In
fact, I'm sure they do because they work very nicely in this context. :)
> but the purpose of this object
> isn't to enforce those rules. Sometimes we have legacy code that
> requires flexability. The design of this component is aimed at
> flexability.
The most flexible, future proof solution is one that does not introduce
naming collisions.
> (On the effeciency rant...
I don't think anyone was ranting. My apologies if you took it that way.
> I aim at SOHO solutions. Perhaps
> in the mega enterprise this would be a bottleneck. I don't have the same
> issue others do.
Agreed. I'm also not generally concerned with squeezing every last bit of
performance out of code. I will always choose readability and manageability
over performance unless performance has become an issue.
> Speed in coding and reuse for more green developers is
> an issue that is being forgotten by us "gurus" of perfection.
I don't think that one implementation is any more difficult to read or use
than the other. Could you provide an example where you feel this is not the
case?
> If we had
> to jump through all the loops we force new programmers to jump through
> we wouldn't have done it. Of course all the rules and regulations we are
> creating should serve some university well to create a classroom cash
> cow. It will take new programmers years to get all of our rules down in
> thier minds. SOHO business can't usually afford our "higher
> reasoning"... and these solutions work faithfully. The efficiency isn't
> that great... and I did shift the evaluation slightly to that piece of
> code.)
It's important to note that ADO functions like what I've described. Most
people, even unseasoned developers, would not say that ADO is difficult to
grasp.
Ben Rogers
http://www.c4.net
v.508.240.0051
f.508.240.0057
----------------------------------------------------------
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]
