Category: Tips

Getting Dumped While Using MXUnit

With all my real world experience getting dumped, I never thought it could ever be a good thing. But in programming, getting dumped, more specifically, dumping variables, is immensely useful when debugging. I use it all the time when writing code.

But having lately been playing more and more with unit testing, specifically using MXUnit in Eclipse, debugging errors through unit testing seemed a bit more problematic.  I could put dumps in my CFCs but that output would never make it to my test case results. How was I expected to debug that way.

Then I had an idea. Stop me if you heard this one.  Instead of using “writeDump”, I raised an error. I used the throw statement. For the error type I put the name of the variable. For the message I put the value of the variable:  For instance, I put:

throw(message=userID, type=”User ID”);

When I run my unit test in Eclipse in my results I see “User ID: 84756”. Voila!  One caveat  however, and it is a big one, it only works with scalar values.  Figuring out how to dump structures and arrays will be my next task.

Always learning….always growing.

Dropping CFScript Functions into Your JS File

This post is about the cool similarities between Javascript and CF Script in ColdFusion.  But since this is my first post, a little introduction is in order.  I have been a web developer since 1996 and started with ColdFusion in 1998.  But once I got to ColdFusion MX, I got in a rut, lost my passion for programming and pretty much took a nap….a long nap….until about 2011. Boy did I miss a lot!!!  It was like waking up to a whole different world!

What an exciting time to be a developer!  With jQuery and a bazillion other JS libraries, MVC  frameworks, CFScript, mobile development, cool things like node.js  (I hear tell it actually flies little helicopters) and even databases without SQL (who knew that was possible), there is so much to learn!  I want to learn it all! But in the meantime, I hope to share some of what I find with you, both in my day to day work, and in memory dumps of things I have picked up since I awoke.  Feel  free to join me in the journey.

What better  way  to kick off  the Script Van Winkle  blog than with a discussion of script.  Before my nap I had programmed a ton in ColdFusion…but in all tags of course.  I had also programmed often in JavaScript, so that was familiar to me as well.  My first thought when hearing you could now do script in CF was,  of course, “why?”.  It did not make sense to me at first.

Despite being a disorganized mess in my private life, I love organization in my code.  I like it to look neat and easy to read.  I love white space and tabbing lines  to make code more readable.  In playing around with CF Script,  I found it looked more organized.  To me,  it seemed much more readable.   So I got it. I thought I had discovered why CF Script was cool.  It’s easier to read.  All the functions in my new or rewritten CFCs are now in script.

But it turns out there is so much more!  I was working on a project at my day job where, when building the page,  a call is made to a third party image renderer  for a preview image.  I have a function in my CFC (in script of course), that builds the URL to use to call the third party rendering.  It works great!

But we wanted to give the user the opportunity to make changes,  have that image rerender  based on those changes, and to do it without  necessarily having to use our server as a go-between.  So I had to write a JavaScript version of the CFC function that built the URL. This is where it got cool!

I copied the CF Script from that function into my JS file. Did it work right away? Of course not.  But it only took a few little adjustments to get it up and running. I did not have to rewrite the whole thing (and my comments didn’t need to change either).

You can do the same thing…just keep a few things in mind:

  1. Don’t forget, arrays in CF start at 1. In JS they start at 0.  This will likely trip you up at some point. Make sure you adjust any loops to reflect that. This usually entails starting loops at zero rather than one, and often your “less than or equal to” comparison to the length of the object you are iterating over, becomes simply “less than” the length.
  2. Speaking of decision operators, operators  such as  “is less than”, “lt”, “lte”, “gt”, “gte”, “is greater than”, “eq”, “equals”, etc.,  need to be changed to the JavaScript equivalents like “<“,  “<=”,  “>”,  “==”, “===”,  etc.  Make sure you have checked all of your loops for this as well.
  3. Speaking of loops, particularly those of the “for” variety, you can replace the incremental in CF with the JS equivalent. For example: “for (intX = 1; intX LT 3; intX = intX + 1)”, becomes “for (intX = 1; intX < 3; intX ++)”
  4. If you are using ArrayLen or ListLen, or just plain Len in CF, change those to use the “.length” function in JS.  For instance: “ArrayLen(aryItems)” becomes “aryItems.length”.
  5. Functions like “Replace” need to be switched out with JS version.  For example “Replace(strTestString, “saint”, “st.”) in CF becomes “strTestString.replace(“saint”,”st.”)  in JS.  There are a few CF functions that fall into this category.  Just figure that any function that takes a variable name as its first argument in CF probably has to modified.

While the amount of changes necessary will depend on the complexity of your particular function, you will more than likely find that a large percentage of the code is unchanged.  This is especially true if your DOM variables on the client side mirror your variables on the server side.  In my case,  I was dropping the entire object containing the graphics information to the DOM via JSON……but that is another post!

There are many reasons why you should switch to using CF Script, these are but two.  Happy scripting!!!!

© 2018 Script Van Winkle

Theme by Anders NorenUp ↑