> But, I do see you're using NOT isDefined("variables.var").
> I've been using NOT structKeyExists(variables,"varName")
> (which I didn't know about until Sean yelled at me for
> using the other method... ;) ) and I can say that it
> dramatically improves clarity, performance, and
> readability. It doesn't use the isDefined() search path,
> it checks the scope (or any struct you specify, actually)
> and immediately reports an answer.
> I've noticed improvements of up to 50-60% in response
> times for
> pages/code that are dependent on the
> isDefined/structKeyExists check
> process.
In my own code I use structKeyExists() _nearly_ exclusively. Which is
not to say that there aren't exceptions. The exception in general is
when either a) I don't actually know what the name of the variable
will be and as a result would have no data to pass to the
structkeyexists() function -- this is an unfortunate circumstance
which arrises occasionally when I want to conditionally check for the
existence of a variable within a function given the name of the
variable -- some variable names are fine in an isdefined() call, other
quite common and perfectly valid variable syntaxes produce an
exception (I think isdefined("myarray[1]") is all it takes)... I would
_MUCH_ rather cf simply return false in _any_ case that the value is a
string which can't be evaluated (rather than a complex object) in much
the same way that isNumeric() will not error when given a complex
object for examination. That not being the case, I end up being forced
to resort to try-catch -- which is an awful way to manage that because
the exception is a waste of resources - but I digress - or b) when I
know that the syntax for the variable will be valid in an isdefined()
call, but I'm not certain all the structures will exist:
<cfif isdefined("request.tapi.db.keys.exported")>
-- now in general, I know that request.tapi exists, but the "db"
library may or may not have been loaded... further if none of the
"db.keys" functions (iirc there are 3 of them) have been loaded, the
db.keys structure won't exist either, so the alternative syntax for
this would be:
<cfif structkeyexists(request.tapi,"db")
and structkeyexists(request.tapi.db,"keys")
and structkeyexists(request.tapi.db.keys,"exported")>
Asside from being three times as much code, it also needs the
structkeyexists() call three times, which means that asside from the
extra code, the 50-60% increase in performance would likely be more
than negated in this instance and the isdefined() call would actually
be more efficient and save some time.
Although as a general rule, I don't consider mechanical efficiency on
the scale of a function like isdefined() or iif() a high priority.
These functions add mere milliseconds (if that) to execution times, so
when I'm working on making an application efficient I focus on much
more productive methods such as database structure/indexes and
incremental caching of complex process results which actually save
orders of magnitude more time in execution and have far fewer points
of impact in the application code.
So the reason I actually use structkeyexists() in the majority of my
code is not for the purpose of efficiency, it's simply for the purpose
of the function being more precise -- of being a more exacting
descrption of exactly what it is I want to know in my application.
When I'm typing out examples for cf-talk or elsewhere I frequently
revert back so isdefined() mostly because it's fewer keystrokes, and
.... this will sound really silly... but I find the "word"
"structkeyexists" to be a particularly annoying word to need to type,
particularly repetitively... the position of the keys on the qwerty
keyboard is just such that "structkeyexists" rather than sort of
rolling easily off of my fingertips is actually a nearly painful
excercise for my hands to work through.
I wonder if that's had an impact on the adoption of a programming
language features in the past? People not using it just because they
find it annoying to type.
> Just FYI.
> </comments destination="S. Isaac Dealey">
> As far as the original question... I've got one situation
> where I'm doing this:
> <cfset var returnData = structNew()>
> <cfstoredprocedure...>
> <cfprocresult name="returnData.descriptor"
> resultset="1" />
> <cfprocresult name="returnData.columns" resultset="2"
> />
> </cfstoredprocedure>
> <cfreturn returnData />
> I don't see a reason to split them up. If the stored
> procedure is a unified method for accessing data, and
> the data is always going to be returned in a block, why
> on earth would it make sense to divide them up into many
> getters/setters? I can see this making sense in
> situations where you may or may not return all the data
> from an sproc call, but in my case I'm *always* going to
> return *all* the result sets. It's not better encapsulation
> to divide it, IMO, in this case... it's a waste of effort.
It would be difficult for me to say without knowing exactly what those
resultsets contain and how their used if I could envision a scenario
in which they're not used together. Generally speaking tho when I
build database schemas, I never really come out with a scenario in
which I have two queries which would always be used in tandem. I do
have situations where it's frequent, or common, or even the majority
of instances, but I've never personally had a situation where it was
the only case. Given the names of your resultsets alone, I would
_guess_ that it might be possible to actually return those as a single
query, although that's just a guess, I have no idea what they actually
do, particularly given that their names are so generic.
If you do have a situation in which you really do need 2 queries that
will never be used in isolation, then no, there's no need to divide
them up. My previous comments were really just an "in my experience"
sort of explanation. And in general I think everything I say (or
anyone says for that matter, including the Bible, the Koran or any
other "holy" book) should be questioned. Use the wheat, discard the
chaff. And I can produce chaff with the best of them. :P
> My other question is this: Why would you write an sproc
> that returns
> more data than you need? That's another waste of
> resources. I would
> also submit that it's a symptom of low cohesion. If your
> needs are
> such that an sproc is required and the results are
> variable, I'd use
> internal logic in the sproc to return the data that's
> necessary.
Generally speaking yes. I wasn't really thinking that far down the UML
diagram tho.
> Now, I can see situations wherein you may have a CFC in a
> shared scope
> that contains query data in it's instance data... if you
> don't need
> all the data all the time but are going to need it at
> various points,
> sure, that makes sense. getDataThis() and getDataThat()
> would be
> sensible. If we're talking about a DAO/Gateway that deals
> with data
> processing for an event, that's where I have questions...
> I'm mostly
> wondering "why would you want to do that anyway?"
You probably wouldn't unless you were actually storing the instance
data in the session, application or server scope. As above -- my
comments weren't intended to be exhaustive in any sense of the word.
s. isaac dealey 954.522.6080
new epoch : isn't it time for a change?
add features without fixtures with
the onTap open source framework
http://macromedia.breezecentral.com/p49777853/
http://www.sys-con.com/story/?storyid=44477&DE=1
http://www.sys-con.com/story/?storyid=45569&DE=1
http://www.fusiontap.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Find out how CFTicket can increase your company's customer support
efficiency by 100%
http://www.houseoffusion.com/banners/view.cfm?bannerid=49
Message: http://www.houseoffusion.com/lists.cfm/link=i:4:197557
Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4
Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4
Unsubscribe:
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
