> I address the "This scope" as attributes. If someone creates a datafield
> that matches a function name they are both existing with simular "name"
> but they are independent unless someone violates good code and uses the
> code to set the this scope.
They don't exist in a "similar" name. One overwrites the other. It happens
on line 138 of your CFC:
<cfset "this.#columnName#" =
variables.query[columnName][variables.currentRow]>
If you query has a column named "isLast", you will overwrite the reference
to you isLast() function because the above code will evaluate to:
<cfset this.isLast =
variables.query[columnName][variables.currentRow]>
> In the oquery.cfc this should be avoided. Only
> the setattributes function should be used... and if you will notice the
> function is private to prevent the outside world from using it.
The setAttributes() function is what causes the problem. It happens
regardless of where it's called from because it blindly creates properties
in the "this" scope. In doing so, it could overwrite references to your
public methods.
> Also... in answer to why I duplicate the query recordset rather than
> referencing it some have asked. It also creates a more encapsulated
> object. It keeps the internals of the object isolated from the outside
> world. They can execute methods... read attributes... and that keeps the
> recordset hidden.
By creating a copy, you're ensuring that no one else can modify it without
going through your component. If I understand you correctly, your goal is to
provide one monolithic component for all your query needs, including
iteration and query manipulation. You think this will be better for new
users (I don't necessarily disagree).
That's one approach. It is more encapsulated, if you think of the ColdFusion
query data type as a simple data structure. However, the ColdFusion query
data type establishes a contract much as a class or interface does. In fact,
under the hood, it really is an object though we don't (usually) treat it
that way in ColdFusion.
You can rely on the query data type to always provide recordCount and
columnList properties. They should accurately reflect the internal state of
the query even after records are added. If the iterator is designed to
handle these changes gracefully (e.g. using variables.query.recordCount and
variables.query.columnList instead of copies), then it wouldn't matter
whether or not we stored a reference to the query or a copy of the query.
Anyway, the only place I really disagree with you is on the name collision
issue. Otherwise, we're just talking about different approaches. I'd prefer
a couple of small components or rely more on the built-in ColdFusion query
manipulation functions. You're looking to build something more
all-purpose...and that's cool too. :)
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]
