Search: parameterExists\(([^)]*)\)
Replace: isDefined(“\1″)

That saved me at least 2 hours

ParameterExists => isDefined is a post from: Blog in Black

Unfortunately, it’s impossible to perform a sitewide search/replace, so I have to open every single file containing CFQUERY tags. To get a list of all the files containing “<cfquery…”, I did a quick

grep -rli “\<cfquery ” > cfqueryfiles.txt

Then, I wrote two tiny regular expressions that make the manual replacing a lot faster:

Step 1: Strings => Varchar
Replace ‘#([^#]*)#’ by <cfqueryparam cfsqltype=”CF_SQL_VARCHAR” maxlength=”50″ value=”#\1#”>

Step 2: Numbers => Big
Replace #([^#]*)# by <cfqueryparam cfsqltype=”CF_SQL_BIGINT” value=”#\1#”>
(Careful! This replaces ANY variable, but does its job inside CFQUERY. Do NOT “replace all”.)

After that, you only have to set the correct sqltypes and/or maxlengths.

cfqueryparam / regular expression is a post from: Blog in Black

“500 the monitoring service is not available”

…on each request, then probably your neo-monitoring.xml is corrupt. This solution did the trick for me:

-Rename or delete the corrupt {cf_dir}/lib/neo-monitoring.xml
-Restart CF

CF then creates a new neo-monitoring.xml, but totally refuses to work if this file has 0 bytes.

The monitoring service is not available is a post from: Blog in Black

If you ever set up a CF 5/6/7 server, you know about the common problems such as non-working apache connectors, Installers that refuse to execute and so on – all that just did not happen. Have a look at my bash_history…

System: Debian Etch netinstall, Installation type: Base system only

apt-get install ssh
apt-get install apache2
useradd coldfusion
cd
ls -la
chmod +x Coldfusion-8-lin.bin
./Coldfusion-8-lin.bin
cp /opt/coldfusion8/bin/coldfusion /etc/init.d/
update-rc.d coldfusion defaults
/etc/init.d/coldfusion start
exit

…and bingo, you end up with a working CF development environment.
The CF installer even managed to install the Apache connector automatically (that NEVER worked for me before).
If that isn’t easy… took me about 30 minutes, btw.

Installing CF8 on Debian Etch is a post from: Blog in Black

-openSuse comes with a 2.2.x Apache
-The apache module shipped with CF is for Apache 1.3.x only
-Adobe offers a 2.0.x module, but no 2.2.x one
-Nextron.ch has a custom built 2.0.4x module that also won’t run on 2.2.x Apaches

So finally, I decided to manually compile the latest 1.3 Apache (1.3.37, wohoo! 1337!), which at least swallowed the standard module shipped with CF. So far, so good, next problem:

-CF refused to start

Well, it wasn’t exactly /bin/cfserver that didn’t start, it was the “start” shell script that fires /bin/cfexec returning “/opt/coldfusion/bin/cfexec: error while loading shared libraries: libdl.so.2: cannot open shared object file: No such file or directory”.

Guess what, assuming that you can trust ldd, the libraries were all there:

ldd cfexec
linux-gate.so.1 => (0xffffe000)
libcfdataaccess.so => /usr/lib/coldfusion/libcfdataaccess.so (0xb7f2b000)
libporting.so => /usr/lib/coldfusion/libporting.so (0xb7ea2000)
libdl.so.2 => /usr/lib/coldfusion/libdl.so.2 (0xb7e9e000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb7e7c000)
libstdc++-libc6.1-1.so.2 => /usr/lib/libstdc++-libc6.1-1.so.2 (0xb7e33000)
libm.so.6 => /lib/libm.so.6 (0xb7e0d000)
libc.so.6 => /lib/libc.so.6 (0xb7cdf000)
/lib/ld-linux.so.2 (0xb7fba000)

So after some pointless trying and debugging (the error message led me into a totally wrong direction), I noticed that the start script does this…

ENV_LIST=”$ENV_LIST LD_ASSUME_KERNEL=2.2.5″

…which reminded me of a SLES10/CFMX7 install I had to do lately. Those of you who ever had to install CFMX7 on a SLES10 machine know that you need to “patch” the installer file by commenting out the “export LD_ASSUME_KERNEL” line inside, so I gave it a try:

ENV_LIST=”$ENV_LIST” #LD_ASSUME_KERNEL=2.2.5″

…and bingo, CF starts.

To sum it up:

-Preferably use a 1.3 or 2.0 Apache
-Install CF as usual
-Change {cfhome}/bin/start as stated above

Easy if you know it, but a pain to figure out

ColdFusion 5 on openSuSe 10.2 is a post from: Blog in Black

It now fully supports UTF8, has a MS-independent codebase and several bug fixed.

Give it a try, you won’t regret!

Ignite Fusion Website

IgniteFusion 2.9b available is a post from: Blog in Black

To let you know the backgrounds of this meeting:

I first got in touch with Ignite Fusion about a year ago due to a mailing list post, so I downloaded it and gave it a try. Without wishing to boast, but I’m sure I’m at least one of the Top5-Bug-/Featurefinders, so the IF team and I are in something that we may call “close contact”.

Ilyas spent his winter holidays in germany, so I did not want to miss the chance to see him. After showing an excellent example of my navigation skills (I really drove a weiiird criss-cross-route in Mönchengladbach), Ilyas, his wife and I met in a cafe in MG-City, had some coffees, talked about indeed almost everything. It started with technical stuff like CF and Ignite, the disadvantages of the german keyboard layout etc. and ended up in talking about the currently unbelievably high petrol prices in germany.

I showed him a small app I coded using IgniteFusion, he let me know some details about Ignite’s history (why/when it was coded) and even unveiled some secrets about what Ignite is able to do, and what is currently planned for the future.

For example, one thing I did not know about Ignite is that it can perform as a standalone socket listener, much like the event gateways in ColdFusion. In a CF template, you say something like

<CFSOCKET name=”blah” port=”999″…>

<CFWHILE TRUE>

(cf code here)

</CFWHILE>

</CFSOCKET>
(don’t know if I got that code exactly right)

Store that in a cfm template, call the ignitedb.exe c:\path_to_template.cfm and ignite will listen on the specified port, executing the cf code inside cfwhile on request to the socket. If THAT isn’t cool!
Unfortunately, this feature is not in the current version (only in V2.3), but will probably be re-implemented in the next release.

Finally, they even gave me a present for Agent R – I was kind of overwhelmed by this. Thanks again for that!

To sum it up: download Ignite Fusion and give it a try! It does a suprisingly good job in interpreting CFML and is simply perfect for small to medium-sized (and maybe large?) CF projects. It’s not 100% CF-Compatible, but somehow “feels” like the real thing, and hey, it’s FREE!

Besides, I’m currently planning an article on comparing Ignite to ColdFusion.
The points I will check are:

-IF’s CFML compatibility
-Bugs I found
-Performance Tests

I’ll post it here as soon as it’s finished.

Ignite Fusion in the house is a post from: Blog in Black

Well, I reached 88% (advanced), mainly because I simply did not remember the syntax of… err… no, I’m not allowed to tell you.

CFMX 7 Developer Certification, Part II is a post from: Blog in Black

If you attended my last presentation on CF performance, you’ll notice that I have some new topics – well, not too many, because hints that were good yesterday are mostly still correct today.

Hopefully, there will be no server crash like last time

See you at 4 o’clock…

UPDATE:
If you missed the talk, here’s the URL of the recorded version:

http://www.msg-webkonferenz.de/p58004826

AgentM on ColdFusion performance guidelines: URL is a post from: Blog in Black

So, what happened?The error occured in the edit handler for the random image object on the Henkel Gateway pages (have a look at henkel.com – the changing image in the upper left corner). To prevent the users from adding too large images, I perform a filesize check using CFDIRECTORY.
I personally like the method of getting the needed information via QoQ, so here’s the code I used:

<cfset theArrayLen = arrayLen(attributes.images)>
<cfset caller.filesizes = arrayNew(1)>

<cfif theArrayLen>
<cfdirectory action=”LIST” directory=”#blahblah#/images” name=”imagedir”>

<!— get the images’ filesizes —>
<cfloop from=”1″ to=”#theArrayLen#” index=”img”>
<cfquery dbtype=”query” name=”getfilesize”>
select size from imagedir
where upper(name) = ‘#ucase(attributes.images[img])#’
</cfquery>
<cfset caller.filesizes[img] = getfilesize.thesize>
</cfloop>

<!— now that we have the directory contents, pass them to the caller for further usage—>
<cfset caller.imageDirContent = imagedir>
</cfif>

CFMX complained about the select “SIZE”, as “SIZE” is a reserved word in SQL. Unfortunately, CFDIRECTORY names its size column like that – there’s no chance to change the name. So I tried the following…

-Using a SQL alias
select size as theSize from imagedir … didn’t work

-Using quotes and / or brackets around “size”
select “size” as theSize from imagedir …didn’t work
select [size]… …guess what – didn’t work

The solution is simply to access the column by its number, as you would do it in an “order by” clause, e.g.

select blah as myBlah, blah2 as megaBlah
from theTable
order by 2

To sum it up:

<cfquery dbtype=”query” name=”getfilesize”>
select 5 as theSize from imagedir
where upper(name) = ‘#ucase(attributes.images[img])#’
</cfquery>

That actually works.
According to the SQL standards, CFMX does everthing right – it’s some kind of careless behaviour of CF5’s QoQ implementation.

Finally, here’s a list of reserverd words in QoQ:
<a href=”http://livedocs.macromedia.com/coldfusion/6.1/htmldocs/express4.htm” target=”_blank”>Reserverd words in QoQ</a>

Reserved words in QoQ is a post from: Blog in Black

If you also administer your server(s), you’ll probably check that folder once in a while, move the undelivered files back to the spooler and check back next time… or week/month/year/life. That generally results in sales persons asking “why the hell did that email need four month to be delivered???”. And hey, they’re even right!

At Henkel, we’re currently running a bunch of CF 5 and CFMX servers in several clustered environments. From time to time, the smtp gateways may be unreachable, and even though we’re checking email address entries before doing a cfmail, some very eager persons manage to misspell them…

To sum it up: I decided to write a template that does the dirty work for me:

• Move all files from the undelivr-folder back to the spooler
• Keep track of them in a database
• Log that action
• Count how many times each mail file has been moved back
• If not sent out for 10 times, move it to a “junkyard” folder

If a mail failed to be sent out for 10 times, there’s probably something wrong with the mail address. Assuming I call the template every 12 hours, a 5-day-timespan is covered, and most likely (or hopefully) the smtp gateway is NOT the reason after five days of sending in vain

So give it a try – originally designed to work on the Henkel systems, I did a quick rewrite of the code to make it work on standard CF machines.

Let me know if it works for you!

Download file

Update: V1.10: Fixes for CFMX7

\cfusion\mail\undelivr is a post from: Blog in Black

A PDF file is available here

Agent M on CF performance tuning is a post from: Blog in Black

Another important fact Ben mentioned was that basically, because of its modularity, CF Blackstone is “CF 6.1 with new features added”.

That might be important to all you guys who are currently planning to migrate to MX: if your app runs on 6.1, it will run on blackstone, because, as Ben said, the core tag’s code stayed the same.

This leads to some interesting migration scenarios:

- If you’re planning to move from CF pre-MX to MX, you might consider trying the blackstone beta simultaneously (or even jump directly to that one . Ben said that 6.1 and blackstone can coexist on one machine without getting each other into trouble.

- The update from 6.1 to blackstone will probably be hassle-free, at least as far as your code it concerned

Ben also told us that he’s running blackstone on some (or all? I forgot that) of his productive servers since the eary alpha days without even one error in the logfiles and no visitor complaining about anything. To speak with him: “blackstone is rock solid”.

Can’t wait until the beta will be announced!

Ben on Blackstone: M’s summary is a post from: Blog in Black

kommentarlos hier mal ein Performance-Vergleich: CFMX auf AMD Opteron bzw. Intel Xeon…

AMD Opteron 248 vs. Intel Xeon 2.8: 2-way Web Servers go Head to Head

Benchmark: CFMX 6.1 auf AMD / Intel is a post from: Blog in Black

Macromedia scheint sich nicht ganz schlüssig zu sein, ob Spectra Open Source (V1.5.3) nun zum Download freigegeben ist oder nicht

Bis gestern war noch folgende, noch im Google-Cache zu findende Seite unter spectrasource.macromedia.com zu sehen:

Spectra 1.5.3 im Google-Cache

Heute ist wieder die alte 1.5.2er Downloadpage zu sehen:

http://spectrasource.macromedia.com

War der Release evtl. verfrüht? Ein Kollege hat die 1.5.3 lokal installiert und war angesichts der Tatsache, dass Spectra ohne weiteres Zutun unter CF6.1 lief (was ja so mancher als “unheimlich” bezeichnen würde , schon ein wenig begeistert.

Warten wir ab…

Spectra Open Source: Ja was denn nu’? is a post from: Blog in Black

Das klassische Beispiel ist wohl das folgende:

<cfquery name="getData" datasource="#request.dsn#">
	select something
	from theTable
	where ID = #url.ID#
</cfquery> 

Was nun geschieht, wenn man die Seite mit page.cfm?id=5;drop%20database aufruft,
kann sich jeder ausmalen (Voraussetzung ist natürlich eine schlecht aufgesetzte
Datenbank)…

Man kann (und sollte!) hier natürlich zu CFQUERYPARAM und generellen
Plausibilitätsabfragen
mit CFIF greifen, allerdings ist dies meiner Meinung nach nur die halbe
Miete. Deutlich sicherer fährt
man, wenn die zu übergebenden URL-Variablen verschlüsselt und somit
weitmöglichst
gegen Manipulation geschützt werden. 100%ige Sicherheit gibt’s natürlich
nie, aber man sollte es den bösen Buben so schwer wie möglich machen.

Das Prinzip

Grundlage des Systems, welches ich mir ausgedacht habe, ist der Custom Tag
cf_cryp von Jackson Moore. Prinzipiell wollte ich erreichen, dass man
sowohl verschlüsselte, als auch normale URL-Variablen übergeben kann,
ohne sich darum kümmern zu müssen, ob nun eine Entschlüsselung nötig
ist oder nicht. Zudem wollte ich erreichen, dass man als Programmierer
keine großen Umstellungen einplanen muss, also ganz normal mit URL-Variablen
weiterarbeiten kann.

Coding

Die Ideale Stelle für eine automatische Entschlüsselung eines verschlüsselten
Querystrings ist natürlich die Application.cfm. Ich nutze hierzu folgenden
Code:

<!--- encryptkey setzen --->
<cfset request.encryptkey="Blog_in_Black">

<!--- wenn ein querystring oder form.values vorhanden ist, string entschlüsseln --->
<cfif (len(cgi.query_string) and not find('=', cgi.query_string)) or isdefined("form.values")>

	<cfscript>
		//je nach situation string und scope setzen
		if(len(cgi.query_string)) {
			decodeme=cgi.query_string;
			scope="url";
		}
		else {
			decodeme=form.values;
			scope="form";
		}
	</cfscript>

	<!--- string entschlüsseln --->
	<cf_cryp type="de" string="#decodeme#" key="#request.encryptkey#">

	<!--- aus dem entschlüsselten string wieder variablen bilden --->
	<cfloop list="#cryp.value#" delimiters="&" index="idx">
		 <cfset name=left(idx,FindNoCase("=",idx)-1)>
		 <cfset wert=right(idx,len(idx)-FindNoCase("=",idx))>

		<cfset "#scope#.#name#" = wert>
	<!--- für's debugging <cfoutput>#scope#.#name# = #wert#<br></cfoutput>  --->
	</cfloop>

</cfif>

Wie man sieht, geht der Code noch einen Schritt weiter und entschlüsselt
bei Bedarf auch den Inhalt von form.values, also ist auch eine verschlüsselte
Übergabe von Formularwerten möglich.
Damit das System in dieser Form funktioniert, musste ich an cf_cryp eine
kleine Anpassung in Zeile ~89 vornehmen:

<cfif findnocase("J",string,1) is 0>
	<!--- <cfthrow type="cryp" message="nochecksum"> --->
	<!---marcus raphelt <cfml@raphelt.de>: added cfexit to suppress exceptions in cfmx--->
	<cfexit method="EXITTAG">
<cfelse>

Der Kommentar sagt’s bereits: unter CFMX gibt cf_cryp eine Exception aus,
wenn der übergebene String nicht dekodierbar ist. Dies wird zwar mit
dem not find(‘=’, cgi.query_string)weitestgehend
abgefangen, aber ich will’s nicht darauf anlegen, denn es könnte auch
z.B. ein Aufruf wie page.cfm?myVar
stattfinden.

Was geschieht nun in der Application.cfm?

Ich gehe hier nur auf die URL-Variablen ein – beim Form-Scope ist es
das gleiche, nur dass eben ein anderer Wert für scope gesetzt
wird. Es wird nachgesehen, ob ein Query-String übergeben wurde,
und ob er kein Gleichheitszeichen enthält (das ist bei mit cf_cryp
kodierten Strings nicht möglich). Ist dies der Fall, so wird
der Query-String an cf_cryp zur Entschlüsselung übergeben.
Zurückgegeben wird dann der "echte" Querystring, z.B. itemID=300&viewmode=full&bgcolor=white,
welcher dann über eine Schleife in Variablen des gewünschten
Scopes, in diesem Fall URL, umgewandelt wird. Das bedeutet gleichzeitig,
dass man im Zieltemplate wieder URL-Variablen zur
Verfügung hat und quasi normal weiterprogrammieren kann.

Übergabe

Den zu übergebenen Wert muss man vorher zusammenbauen und verschlüsselt übergeben.
Hier ein kleines Beispiel:

<!--- zu übergebenden querystring zusammenstellen --->
<cfset theQueryString = "itemID=300&viewmode=full&bgcolor=white">

<!--- querystring verschlüsseln --->
<cfmodule
	template="cryp.cfm"
	type="en"
	string="#theQueryString#"
	key="#request.encryptKey#"
>

<cfoutput>
<a href="index2.cfm?#theQueryString#">Normale Übergabe...</a><br>
<a href="index2.cfm?#cryp.value#">Verschlüsselte Übergabe...</a></cfoutput>

Ergebnisseite

Auf der Ergebnisseite reicht ein Dump des URL-Scopes. Sorry an alle 4.x-User,
aber ich war zu faul, eine Loop zu nutzen.

<cfdump var="#url#">

Erweiterbarkeit

Das System lässt sich natürlich in alle Richtungen erweitern. So könnte man
z.B. verschlüsselte Werte in Cookies schreiben oder Variablen, die im
Server-Scope liegen, vor unbefugten Blicken schützen (praktisch bei Virtuellen
Servern).

Nachteile

Ganz klar, durch die Ver-/Entschlüsselung hat man deutliche Performance-Einbußen.
Diese sind aber, wie ich finde, wegen der gewonnenen Sicherheit zu vernachlässigen.

Download

Natüüürlich – Abtippen wäre unnötiger Sport. Daher habe ich ein kleines ZIP-Archiv (5521 Bytes)
erstellt, in dem alle nötigen Dateien enthalten sind. Viel Spaß beim
Testen!

Feedback ist erwünscht!
agent m, 07.10.2003

Verschlüsselung von URL-Variablen is a post from: Blog in Black

Einige werden sich sicherlich Fragen, warum ich eine mehrwöchige Schreibpause
eingelegt habe – nun – ich war nach einer Gehirnwäsche eine Zeit lang
Oberpostvorsteher
in einem kleinen Dorf und… ach nein, lassen wir das… zum Thema!:-)

Ich hatte sehr oft Aufträge à la "kannst Du das mal eben
schneller machen?"
und bin dabei häufig auf eine Programmiermethode gestoßen, die gerne
z.B. zum Darstellen von Artikelübersichten in Shops genutzt wird:

<cfquery name="getItems" datasource="shopDB">
	select itemID, itemName
	from items
	where group = #url.group#
</cfquery>

<cfoutput query="getItems">
	<cfquery name="getDetails" datasource="shopDB">
		select onStock, whatEver
		from items
		where condition = true
		and itemID = #getitems.itemID#
	</cfquery>
	We currently have #getDetails.onStock# x #getItems.itemName# on stock.<br>
</cfoutput>

Das Prinzip ist hierbei, dass eine Hauptquery die Loop-Basis bildet und in
der Loop dann weitere Details geholt werden. Sicherlich werden viele
das Prinzip wiedererkennen. Okay, der Code ist relativ sinnfrei, es geht
mir hier aber lediglich um’s Prinzip.

Um hier mit relativ wenig Aufwand eine deutliche Steigerung der Performance
zu erreichen, kann man die erste Abfrage sozusagen als BaseQuery definieren
und weitere Abfragen mittels QoQ gegen dieses Queryset laufen lassen.
Somit ist die Datenbank entlastet:

<cfquery name="itemBase" datasource="shopDB">
	select itemID, itemName, [...]
	from items
	where group = #url.group#
</cfquery>

<cfoutput query="getItems">
	<cfquery name="getDetails" dbtype="query">
		select onStock, whatEver
		from itemBase
		where condition = true
		and itemID = #getitems.itemID#
	</cfquery>
	We currently have #getDetails.onStock# x #getItems.itemName# on stock.<br>
</cfoutput>

Alle Queries innerhalb der Schleife holen sich ihre Daten nun aus dem RAM.
Dieser Tip ist z.B. für diejenigen interessant, die mit CF und Access
arbeiten (müssen). Access ist irgendwann am Ende seiner Kräfte,
daher sollte man’s entlasten, wo nur eben möglich.

Gute Zeilen, schlechte Zeilen – Folge 5 – Query of Queries is a post from: Blog in Black

als Suchbegriff bei Google eingegeben?

Google kennt derzeit ca. 601000 Einträge von CF-Templates, bei deren Indizierung eine CF-Fehlermeldung ausgegeben wurde. Das ist Google natürlich herzlich egal, die Seite wird trotzdem in den Index aufgenommen.Das ist eine ziemlich fatale Sache, denn so bekommt man wunderbar und brühwarm die möglichen Angriffspunkte für fehler-/mangelhaft programmierte Webseiten aufgelistet. Ich habe auf die Schnelle mindestens zwei Sites gefunden, denen ich mit URL-Hacking das Leben hätte schwer machen können…

Ein Gegenmittel gibt’s leider nicht, außer man programmiert die Seiten entsprechend fehlerresistent.

Link hierzu:
Google mit o.g. Suchbegriff

Google fatal is a post from: Blog in Black

In der CF-Mailingliste kam kürzlich die Frage auf, welche Art von Schleifendurchläufen
bei der Verarbeitung von Querysets performanter ist – CFLOOP oder CFOUTPUT.
Hätte ich in CF 4.x / 5.x noch blind auf CFLOOP getippt (daher stand es nach der ersten Halbzeit auch 1:0 , so ist das ganze in
CFMX etwas anders…

Summa summarum: es gibt keine nennenswerten Unterschiede mehr, zumindest keine,
die die eine oder andere Vorgehensweise rechtfertigen. Mal ist CFLOOP schneller,
mal CFOUTPUT, aber in keinem Fall war der Unterschied so nennenswert groß,
dass man wegen der Performance umschwenken sollte, selbst eine mit CFSCRIPT
angelegte Schleife war gleich schnell.
Um aber eine gewisse Konsistenz in den
Quellcode zu bringen, würde ich immer noch
folgende Richtlinien empfehlen:

• Bei Schleifendurchläufen, in denen eine Ausgabe erfolgt, also HTML zum
  Browser gelangt, sollte CFOUTPUT genutzt werden
• Ist dies nicht der Fall, also z.B. bei reinen Berechnungen, würde ich CFLOOP
  vorziehen.

Damit es auch dieses Mal wieder etwas zum "Anfassen" gibt, hier noch der Quellcode,
mit dem ich die Messungen durchgeführt habe:

<!---queryset erstellen--->
<cfscript>
   numberOfRecords = 1000; //anzahl der zu erstellenden demo-datensätze
   theQuery = QueryNew("name, strasse, telefon, email");
   QueryAddRow(theQuery, numberOfRecords);
</cfscript>

<!--- 1000 demo-datensätze füllen--->
<cfloop from="1" to="#numberOfRecords#" index="x">
 <cfscript>
   QuerySetCell(theQuery, "name", "name_#x#", x);
   QuerySetCell(theQuery, "strasse", "strasse_#x#", x);
   QuerySetCell(theQuery, "telefon", "telefon_#x#", x);
   QuerySetCell(theQuery, "email", "strasse_#x#", x);
 </cfscript>
</cfloop>

<cfloop from="1" to="10" index="y">
<!--- <cfoutput query="theQuery"> --->
<!--- <cfloop query="theQuery"> --->
<!--- <cfscript>
   currentName = theQuery.name;
   currentStreet = theQuery.strasse;
   currentPhone = theQuery.telefon;
   currentEmail = theQuery.email;
 </cfscript> --->
 <!--- <cfscript>
   for(x = 1; x lte numberofrecords; x=x+1) {
   writeOutput(theQuery.name[x] & ' ');
   }
 </cfscript> --->
<!--- <cfoutput> #theQuery.Name# </cfoutput> --->
<!--- </cfloop> --->
 <!--- </cfoutput> --->
</cfloop>

Ich habe hierbei jeweils bei den passenden Codestücken die Kommentare wieder
entfernt, so dass ein einfaches Hin- und Herbewegen zwischen den verschiedenen Befehlen
relativ schnell möglich war.

Mich würden natürlich auch die Messwerte anderer interessieren, also wenn jemand
Zeit hat – immer her damit.

Gute Zeilen, schlechte Zeilen – Folge 4 is a post from: Blog in Black

Genau dies ist die häufigste Frage, die man CF stellen sollte, denn mit boolschen
Abfragen kommt es mit Abstand am schnellsten zurecht. Wann immer möglich, sollte
man daher versuchen, IF-Abfragen nur nach true oder false auszuwerten.

Ein paar Beispiele hierzu:

Wenn ein Wert sowieso schon im boolschen Format vorliegt, verschenkt man mit
der linken Variante Zeit, denn in dieser Form wird "true" von CF als String verglichen,
und Stringvergleiche sind de facto langsamer.

Das sind einige Standardkandidaten, die ich in "zu tunenden" Applikationen
immer wieder finde.
Im ersten Fall ist blah eine Zahl, man kann sich das gt
0 also komplett sparen,
da Zahlen > 0 von CF als true angesehen werden.
Der zweite Fall fragt ab, ob blah kein Leerstring ist, aber – wie der Name
schon sagt, es ist eben ein Stringvergleich. len() liefert die Länge des Strings,
also eine Zahl zurück, und diese wird, wie bei Fall 1, als true angesehen,
sofern sie > 0 ist.
Fall 3 zeigt das umgekehrte Beispiel mit not
len(), also wenn 0 als Länge zurückgegeben
wird.
Fall 4 macht sich die Funktionsweise von compareNoCase() zu nutze: bei Gleichheit
zweier Strings wird 0 zurückgegeben, und die ist – jepp, false.

Wirklich, das habe ich *echt so* vorgefunden. Die Stringabfrage nach "yes/no" muss natürlich weg, das zweite fileExists() macht noch weniger Sinn,
denn wenn die erste
Abfrage
false zurückgibt, muss man nicht noch einmal abfragen, ob die Datei nicht vorhanden
ist.

Wenn man sich sich an diese Art des Abfragens gewöhnt hat, spart man deutlich
an ExecutionTime. Dies alles sind zwar nur kleine Effekte, aber wenn
man nur 10ms Prozessorzeit pro Aufruf spart, spart man bei 5.000 Aufrufen 50s.
Wie sehr sich dies bei HighTraffic-Sites summiert, kann man sich ausrechnen…

Gute Zeilen, schlechte Zeilen – Folge 3 is a post from: Blog in Black