Marcus's Musings

Code Snippets (I)

A few simple but handy snippets of code for you...

Kill
Firstly, since I use it in almost every function which uses objects, I thought I'd better repost Kill(), which tidies up objects and arrays, with special handling for ADO and Dictionary objects.

NOTE: All code posted on this blog from now on will assume that this function is part of your includes

Function Kill(byref Obj)
	Select Case True
		Case IsObject(Obj)
			Select Case LCase(TypeName(Obj))
				Case "recordset", "command", "stream", "connection"
					'ADO objects
					If Obj.State <> 0 then
						Obj.Close
					End If
				
				case "dictionary"
					'remove all the pairs
					Obj.RemoveAll
					
				Case else
					'something else so don't
					'do anything special
					
			End Select
			
			Set Obj = Nothing
		
		Case IsArray(Obj)
			'clear the array
			Erase Obj
		
		Case Else
			'do nothing at all
			
	End Select
		
	'Now revert it to an unitialized state
	Obj = Empty
End Function

IsBlank
This is another of my most frequently used snippets, which acts as a catch-all checker for variables, meaning that you no longer have to worry about the variable type when you want to use a If MyVar="" Then statement. It will automatically test the variable using all the appropriate checks - see the code for exactly what it does and how. Simple, but remarkably handy! Give it a go next time you write a complicated script or entire app!

NOTE: All code posted on this blog from now on will assume that this function is part of your includes

Function IsBlank(ByRef Var)
	IsBlank = False
	
	Select Case True
		Case IsObject(Var)
			If var Is Nothing Then
				IsBlank = True
			End If
		
		Case IsEmpty(Var), IsNull(Var)
			IsBlank = True
			
		Case IsArray(Var)
			If UBound(Var) = 0 Then
				IsBlank = True
			End If
		
		Case IsNumeric(Var)
			If (Var = 0) Then
				IsBlank = True
			End If
			
		Case Else
			If Trim(Var) = "" Then
				IsBlank = True
			End If
	End Select
End Function

ToggleVariable
Invaluable for all sorts of situations where variable needs to flip-flop between two values - one example being alternating colours for table rows.

'Toggles a variable between two values, and will initalise
'the variable to the "on" state if it doesn't have either value
Function ToggleVariable(Byref Variable, ByVal StateOn, ByVal StateOff)
	If (Variable = StateOn) Then
		Variable = StateOff
	Else
		Variable = StateOn
	End If

	ToggleVariable = Variable
End Function

For example:

For N = 1 To 10
	Response.Write "<" & "tr bgcolor=""" & ToggleVariable(C, "#ffaaaa", "#aaffaa") & """>"
	Response.Write "<" & "td>" & N & "<" & "/td>"
	Response.Write "<" & "/tr>"
Next

(tags are broken up to circumvent posting problems in this blog)

Note that although it's a function which returns the new value, it does directly modify the variable (because it's passed ByRef) and therefore can be called as a sub too:

For N = 1 To 10
	Call ToggleVariable(OddRowIndicator, True, False)
	If (OddRowIndicator = True) Then
		'do something here
	End If
Next

GetCurrentURL
Sometimes it's handy to know what the current URL is within your script, but strangely enough ASP doesn't expose this information directly, instead it must be assembled from various server variables. Here's a little function which does it for you:

Function GetCurrentURL()
	'Select the protocol
	If request.servervariables("HTTPS") = "on" Then
		GetCurrentURL = "https://"
	Else
		GetCurrentURL = "http://"
	End If
	
	GetCurrentURL = GetCurrentURL & Request.ServerVariables("SERVER_NAME")
	
	If (Request.ServerVariables("SERVER_PORT") <> 80) Then
		GetCurrentURL = GetCurrentURL & ":" & Request.ServerVariables("SERVER_PORT")
	End If
	
	GetCurrentURL = GetCurrentURL & Request.ServerVariables("URL")
	
	If (Request.QueryString <> "") Then
		GetCurrentURL = GetCurrentURL & "?" & Request.QueryString
	End If
End Function

IIf
And last but not least here's, a handy VBScript version of a VB statement which is also commonly used as a macro in C/C++. This snippet lets you condense a simple "If...Then...Else...End If" block into a single line.

'Immediate If
Function IIf(Condition, ValueIfTrue, ValueIfFalse)
	If Condition Then
		IIf = ValueIfTrue
	Else
		IIf = ValueIfFalse
	End if
End Function

For example, you could turn this:

If IsNull(Price) Then
	Response.Write "(n/a)"
Else
	Response.Write Price
End If

Into this:

Response.Write IIF(IsNull(Price), "(n/a)", Price)

However, let me just make you aware of a slight caveat that presents itself when using this shorthand form...

Let's say that we wanted to format the price as a number with 2 decimal places - one might naturally use FormatNumber(Price, 2) to do this and insert it into the code like so:

Response.Write IIF(IsNull(Price), "(n/a)", FormatNumber(Price, 2))

Unfortunately, this won't work. When you call a function or sub, all parameters are passed either ByRef or ByVal, but regardless it is either a variable (which may contain an object, array, or value) or a value which is passed. Therefore, all three parameters to the IIF function are evaluated before the function is called, and the resulting values are passed.

The consequence of this is that if the variable Price is ever Null, the script will throw an error, because FormatNumber() chokes on Nulls. Therefore, be careful about how you use this and remember that is not quite a 1:1 replacement for the full statement block.

That's all for now, if you have any questions please post a comment and I'll be sure to answer it.

New demo of new trick of old dog

A couple of posts back I shared my GetFolderAsRecordset() function, but I forgot to post a related snippet of code - here's a function which returns the last modified date/time of the most recent file in a given folder, something which is pretty longwinded to do with the FSO, but with GetFolderAsRecordset() in place it only takes a couple of lines (you could compress it into 4 if you used the code inline):

Function GetMostRecentFileDate(FolderPath)
	Dim FolderRS
	Set FolderRS = GetFolderAsRecordset(FolderPath)
	If Not FolderRS.EOF Then
		FolderRS.Sort = "Modified DESC"
		GetMostRecentFileDate = FolderRS("Modified")
	Else
		GetMostRecentFileDate = Null
	End If
	Kill FolderRS
End Function

This function comes in very handy for some data import systems that I wrote at work (each daily import file is a complete data set, not a delta, so I only need to select the most recent one to import - there may be many queued there under various circumstances). I'm sure that you can think of plenty of ways that you could use and adapt this for your own applications...

Festive Merriment

Just a quick post to wish you all a (belated) merry xmas and a happy new year! I hope you have a great time on friday night, and you'll be pleased to know that one of my new year's resolutions will be to post here more often.

In the past calendar year the amount of hands-on coding that I've been doing has dropped dramatically (to virtually none at all), and I also left the forums at SitePoint.com and Codingforums.com because I felt that I'd devoted enough of my free time to helping others over the years and I thought that it was about time I spend more of my time doing other things. Well, I've certainly been busy in the evenings, and I've been having a great time, perhaps too much fun - I've been neglecting this blog and haven't done any ASP coding for myself (i.e. on my site) for a loooong time!

However, in the coming months there's a few ASP projects that I'll be getting stuck into (both at work and at home), and so it's only natural that I'll start to post more frequently here. I'll share code where I can, and if there are any particular topics that you'd like me to cover, such as particularly complex techniques (multi-record form data processing, for example) then drop me a line and I'll see what I can do.

See you in 2005!

Old dog... new tricks?

Most ASP developers seem to have jumped on the ASP.Net bandwagon already, but I thought I'd spread a little love among the remaining ASP classic developers by sharing some of the handy functions & subs that I've developed over the years. I've been meaning to do this for a while, but I simply haven't got round to it until now... my apologies!

I posted quite a few snippets of code on my old blog, so have a look at see if there's anything of interest to you there.

One thing I mentioned there (and provided code for) was the concept of disconnected recordsets, but I didn't really go into what they can be used for, so here's one great use for them - directory listings.

It is often desirable to manipulate a number of files (or subfolders) within a folder, but unfortunately doing so with the FSO is rather longwinded, particularly if you're only processing a subset of the files - all files in "c:\Gallery\" ending in ".jpg" which are less than 1MB in size. Wouldn't it be great if you could retrieve these as a list which could be iterated through?

Well now you can - behold GetFolderAsRecordset(), a function I whipped up a while ago (and recently enhanced) which returns the contents of the specified folder as a disconnect recordset, with each file and folder represented as a record. The name, extension, size, created date, and last modified date of each item are represented as fields, there's a fields to indicate whether the item is a file or folder, and finally there's a field which indicates whether the item can be accessed (it may not if the process under which the script runs has insufficient rights to access the file/folder).

By representing the folder in this way, a number of options are opened up. Firstly, the selection of certain files via particular criteria becomes simple, thanks to the .Filter property. For example, to turn the hypothetical mentioned earlier into reality, all you need to do is this:

Set FolderContents = GetFolderAsRecordset("c:\Gallery\")
FolderContents.Filter = "Type='File' AND Extension='jpg' AND Size<" & 1024^2

While Not FolderContents.EOF
	'Do something here

	FolderContents.MoveNext
Wend

NOTE: The Type='File' criterion is needed because folders can have extensions too... I can't remember EVER giving a folder an extension, but it's been possible since MSDOS v1, so assume nothing!

Secondly, by default the function groups the folder contents by type (folders and files) and then sorts alphabetically. However you can easily change this by setting the .Sort property (e.g. FolderContents.Sort='Size DESC')

Then, there's persistence and XML - by calling the recordset's native sub .Save() you can turn the recordset into XML, save it to disk, and then retrieve it another time. Alternatively, by specifying an ADO Stream object as the output rather than a file and then transforming the XML with some XSLT, you can generate a cleaner output (XML or otherwise) which could be used for all sorts of things (the response to software auto-update request, perhaps)

Most people use recordsets for the retrieval and manipulation of tabular data, and this is no exception - it's childsplay to dump the recordset contents to an HTML table, and enabling sortable columns would take only a couple of lines of code! It could even form the part of one of those "file manager" web apps.. as if there aren't enough of those around already!

I've recently used it as the core for an image batch processing script at work, and it's also very easily to modify the above snippet to generate a quick'n'dirty list of files which meet certain criteria (perhaps for pasting into an email) something which should be part of Windows Explorer, but sadly isn't (although I am aware that numerous directory listing shell extension utils have sprung up to fill this niche). Anyway, I hope you find it useful - it has certainly saved me hours of coding on numerous occasions!

And now the moment you've all been waiting for - the code! As well as the function discussed above, there are also a few handy wrapper functions for creating folders, moving files, copying files, deleting files, renaming files, etc. Nothing special, but it's nice to be able to call them as a one-liner!

It would be nice to get some feedback, so if you find it useful or have problems/suggestions, please post a comment! If this goes down well I may be inclined to release more code in the near future...

NOTE: I have intentionally instantiated all objects in the code with a call to CreateObject() because the code is equally useful in Windows shell scripts, and by using the generic CreateObject() form, the code can be used for either without requiring changes. And in case you're wondering why you need to use the host-specific form at all (i.e. Server.CreateObject() or WScript.CreateObject()), you're not the only one! However, all-knowing scripting guru Eric Lippert was kind enough to provide some answers when I asked him a while ago, so read up (comments too)!

New Article

I've been away in Ibiza for a week (yes, I'll be posting photos soon) and I've just got back to find that the kind folks at ASP 101 have published my new article about VBScript String Concatenation (And Why It Should Be Avoided Like The Plague).

Let me know what you think!

Article no-no?!

After waiting a month for it to be considered, SitePoint got back to me to tell me that they aren't interested in publishing my article regarding VBScript string concatenation and scalable alternatives (a topic which is still very much ignored by ASP developers, and to their peril!) because they are "no longer actively covering ASP".(or words to that effect - the quote is currently from memory, I'll post the exact quotation when I get home to Outlook)

So that makes it official - as far as they are concerned, ASP is dead. Perhaps that's understandable - if not *actually* dead, it's *very nearly* dead, and taking its last steps down the path of obsolesence.

However, that isn't stopping plenty of people from continuing to develop new applications in it - many developers haven't made the switch to .Net (myself included), so it's a real shame that they've decided that it's simply not worth catering to that particular audience at all any more. What's next? Shut down the ASP forum? I hope not.

It's also rather disappointing on a personal level, because (for those of you who don't know) I've been the community-voted "SitePoint ASP Guru" for the past two years and recently resigned as Mentor, so I wanted to have an article published there as a parting gift.

Nevermind, I'll approach www.15seconds.com (who published my first article "Do Stored Queries Increase the Speed of Access Queries?") and see what they think...

Reading Roundup 20/08/2004

Error Handling in VBScript, Part One
Eric continues to demystify the inner workings of the VBScript engine with another excellent post

ASP hints & tips

Here's an excellent site which I learned a lot from many years ago, and which I still link to in various forums posts here and there, but have never mentioned directly...

http://www.motobit.com/ (formerly www.pstruh.cz)

Apart from having some great ASP coding tips, Antonin Foller also offers one of the best script-only file upload processing scripts that I've seen (called "Pure ASP Upload"), which I drew ideas from when I wrote my own class.

In any case, I highly recommend a browse through his site... you're sure to find something of interest!

Redundant Functions #1

The VBScript RGB() function.... Ever used it? No, me neither, and I don't think that's going to change...!

And surely the extra function in the example should be called "BGR()", not "RevRGB()"?!

Typelib recall!

When giving ASP advice in the various forums that I frequent, I've always recommended that ASP'ers abandon the old-style ADOVBS.INC inclusion file for their constants, and instead turn to direct Typelib importing via a METADATA tag.

However, it would appear from the Microsoft Scripting guru himself (that would be Eric Lippert, btw) that importing typelibs is in fact significantly slower than using constants defined in a script...

I've grabbed the latest ADOVBS.INC from the Microsoft MDAC 2.8 SDK and have made it available for download here.

It would appear that it was last updated in 1998 (presumably there haven't been any new constants defined since then), so you may have it already, but please check, because some sources are still offering earlier versions, such as 4GuysFromRolla (which offers the 1996 version, and lacks many newer constants, such as those relating to the rather handy ADO.Stream object).

I hereby formally retract all previous recommendations of using typelib importing... for ASP anyway, the performance hit isn't an issue in WSH, so you should still use it for that scripting environment.

I suggest that if you want to squeeze every last drop of performance out of your web app, you should go back to using ADOVBS.INC.

However, it's not worth losing sleep over - don't forget that everything's not always all about performance... importing typelibs is a little tidier and is futureproof so long as you don't specify the version.

More XML DOM caching + Access stored queries

I've been doing some PC housekeeping and rediscovered a couple of excellent articles that relate to storing an XML DOM in-memory (i.e. in the Session or Application collections), and I can highly recommend giving them a good read:

Creating an In-Memory Database Using XML and XPath -- Part 1
Creating an In-Memory Database Using XML and XPath -- Part 2

While I'm citing articles at 15Seconds.com, here's a good article from 15Seconds on what to take into consideration when optimizing database performance:

Database Performance Philosophy

And finally, those of you persisting on using a JET4/Access database as a backend for your site might be interested to read the following 15 Seconds article written a while ago by yours truly, covering the significant peformance increases available from Access stored queries (as well as testing the best performing query execution syntax):

Do Stored Queries Increase the Speed of Access Queries?

Note to self: what a dumb title!

Microsoft bad practice shocker!

While researching my response to the issue raised in a thread at SPF, I made a startling discovery...

Many years ago, giving ASP include files ".INC" extensions was considered standard practice, until the huge problem with this approach became evident - the full source code of these files (yes, the ASP source code, including all comments) could be retrieved simply by accessing the URL of the include file!! This worked because IIS was (by default) configured to serve requests for .ASP and .ASA files through the ASP engine, but .INC files were served up as plain text, thereby disclosing their contents!

This potentially *huge* security flaw - huge because exposing business logic is bad enough, but lots of bad developers like to hardcode IPs, database names, and even usernames & passwords, which if exposed to outsiders could be expoited to devastating effect - quickly became known throughout the ASP development (and of course hacking) communities via various security bulletins and articles (this being one... I don't have time to track down more right now - I should have gone to bed hours ago but keep getting sidetracked), and include files were renamed to have ".ASP" extensions instead.

Another alternative fix was to simply remove world-readable permissions from the include folder of the web site. Even better was to do *both* just in case another vulnerability exposed the files' contents again, which is precisely what happened with the "::$DATA" flaw (or did that one come first, I don't recall)...

Anyway, this all happened about 6 years ago (I think), but lo and behold, what do I find in the Microsoft ASP documentation, referred to every day by countless developers in their local IIS help files, the platform SDK and online at MSDN??

I'll tell you what... this:

Included files can have any file name extension, but a recommended practice is to give them the .inc extension.

WHAT?!!!

Years after this practice became virtually outlawed, Microsoft still *recommend* it?! I wonder how many developers are blindly following this and STILL giving their include scripts ".INC" extensions, thereby potentially exposing their source code to the world (or at least to malicious individuals)?!!

Naturally, I've made the appropriate feedback submission to the MSDN site, but I wonder how long it will take to fix this astonishing blooper... start your watches please, gentlemen!

XML DOM caching

Since it cropped up in a recent thread at Sitepoint Forums, I thought I'd quickly revisit the topic of caching XML, which I touched on briefly last month.

Since (in the web app I'm developing) I need to store hierarchical navigation & security data which is queried and rendered on every page but which is not modified within the app itself, XML is the logical choice, and being able to cache the parsed XML and XSLT documents to minimize the marginal cost of each hit is the icing on the cake.

I load the main document into a free-threaded XMLDOM object, and store it in an application variable. The XSLT is stored in an XSLTemplate object in a similar way. The menu is then rendered dynamically using 4 parameters, and the security is enforced by direct queries of the DOM. This allows me to include this functionality easily in pages in the site, and eliminate (at least) two database calls on every page (which would have been needed had I approached the problem with a database backend).

However, using this approach is clearly only suitable for data which is not being changed, since the data must be modified sequentially by each page thread (rather than concurrently), because otherwise data will be lost. This is nothing new, and is precisely why the Application.Lock and Application.UnLock methods are there, but (in theory) it severely reduces the server throughput, since each page modifying the data must queue up to read it, as must each page reading it, otherwise it's possible that a read might occur in the middle of a write. Also, since the .Lock and .UnLock methods operate on the entire Application collection (not just the variable you're modifying or reading), the performance hit may be even more significant that you might expect.

It's also worth mentioning that any data stored in the application or session collections is lost when the application is ended/restarted (both) or the session is ended/expires (only the latter), so if it's important you must save the data BEFORE these events occur to ensure that you don't lose valuable data! Again, since my data is read from files on disk, this is no problem.

So, if you need to modify the data regularly (such as in a shopping cart application, as in the example in the thread - see earlier) you should use a data storage medium which is stateless so that you never lose data, for which a database is ideal.

While you *could* save the XMLDOM back to disk every time you modify it, it's rather costly in terms of performance and will probably negate any gains you made by choosing a XML DOM in the first place!!