Note: This blog post is from 2006. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

I was originally planning to dive into the features and use of FusionDebug, but if you followed the comments to my entry last night you will have noticed that there was quite a discussion from some arguing "why should I bother with or care about step debugging? I can get all I need with CFDUMP."

I'd like to address that sentiment in this entry, showing the many ways (13, to start) that interactive step debugging can indeed be a valuable tool in the arsenal of a CFML developer, to solve problems they might otherwise find very difficult.

(I fear that if I instead proceeded with taking the time to first show the tool, some would stop listening because they have preconceived notions of what it is and can--or can't--do. More than that, I bet some will be surprised that it does things they never expected were possible, whether that perspective was formed by their work with debuggers in other languages or in the CF4/5 debugger.)

You can't always do a CFOUTPUT/CFDUMP

As others have commented, a first reaction some may have is that they can do all the debugging they need by using judicious (or indeed copious) CFOUTPUTs and CFDUMPs, or perhaps CFTRACE or CFLOG.

One problem, though, is that there are places where you can't create output.

For example, within a CFC or method where OUTPUT="no" has been set, CFDUMP and CFOUTPUT create no output. Now, you may think, "well I can just disable it," but there are times when doing so will introduce errors or otherwise unexpected results.

Another situation in which you can't create output is within CFSILENT. No output is rendered to the browser. Especially in complex apps and most frameworks, it's common for CFSILENT to be used, and you will have to find and edit the file that sets that to disable it while you do your debugging. There may be a negative impact by disabling the CFSILENT as all the code between there and what you're looking at executes.

Finally, you'll also need to remember to set all those changes back. (More on that later.)

You don't always have a browser to output to (Flex, Ajax, Web Services)!

The point above was about whether you could or could not use CFOUTPUT/CFDUMP. Beyond that, what if you're writing CFML code that is called by a Flex or Ajax client, or that's called as a web service? You can't then always reasonably add debugging output--and you certainly can't do a CFDUMP, if the client is expecting XML, since CFDUMP creates a big HTML table.

FusionDebug can indeed be used for debugging requests from Flex, Ajax, or web services apps. Indeed, it can intercept a call from any kind of client that requests a CFML page or CFC. More on that in a moment.

Now, some may point out that you could in such a case use CFTRACE or CFLOG to write out such output to a log file, and that's so, but it's certainly not as simple as dumping output to the screen.

You can intercept and debug a request from any user, not just the developer

This is a very important point, and actually is an extension of the point above. Unlike the CF4/5 debugger, FusionDebug is NOT limited to only debugging what you as a developer can browse yourself. It can intercept and show to the debugging developer the step-by-step execution of any template or CFC (or custom tag or included file) run by anyone in any manner. So you can use it to debug when someone else is running the request (where writing output to the browser would go to someone other than the developer). I know that may sound a warning bell to some. Hold that thought for a moment, and through the next couple of points.

You can debug a remote machine!

This may be the most powerful feature to some. FusionDebug can do debugging against any CFMX server for which it's been configured. It doesn't need to be just a CF server on the same machine running Eclipse. Not at all.

In a comment in my last entry, developer Tony Petruzzi said, "I believe that if FD had a remote debug like VS.net does, then it would be more appealing. Most of the time you need a step debugger when something totally whacky is happening and usually this occurs when the application is in production."

Well it does indeed do that, and his comment leads to yet another benefit.

You can debug against production!

As stated above, often the challenges you face are ones that you can't recreate in your development environment. Because of its design, there's absolutely no reason you couldn't do debugging against a remote server (production) and with the real end user running the request that's causing the problem you want to debug.

Of course, the above three points represent a two-edged sword. You can't currently limit the debugging to take place only for a given user, so if indeed you are using it on a server being used by multiple users, it will impact anyone who makes the request while you have debugging enabled.

Again, there's much we've not yet discussed on using the tool, so let me be clear: for this to happen, a) a developer would have to have opened Eclipse with FusionDebug, b) turned on debugging against that application/project, c) enabled a breakpoint for a given template, and d) the user would need to request that page and run through that code that would hit that breakpoint. (I'll discuss the details of enabling the debugger and setting a breakpoint in future entries, or it's discussed on the FusionDebug web site).

In such a case, a user would see the page appear to hang until the developer with debugging enabled responded to let the page proceed. I don't say this to scare you: it's just a responsibility to be aware of that comes with the power of the tool. (There's also some modest impact in configuring the server's JVM config to support debugging, so you may want to think carefully about leaving it enabled all the time in production. Again, I'll discuss this point in more detail in a later entry.)

There's no need to change code to get debugging info

With the previous points focusing on some of the unusual and surprising aspects of where and when you can use the tool, I don't want to lose sight of a very important point, perhaps too easy to miss. While some would argue they could just throw some CFOUTPUT/CFDUMP tags in to the code to do debugging, that's clearly less palatable to do in production.

Or perhaps you are doing debugging against some code that someone has ruled that it should not be touched (edited), or it may well be in a directory where you don't have access to edit the code to add any debugging tags. Or, as was discussed in one of the first points, even if you DO disable CFSILENT or the OUTPUT attribute of a CFFUNCTION of CFC, you have to remember to re-enable those when done debugging.

This calls for clarifying a key point: FusionDebug does not require that you edit the code. Again, we're a little ahead of ourselves if you've never seen a debugger and don't understand what setting breakpoints is about. Take my word: it's trivial.

You don't need to be able to enable CF's debugging output

Related to the above points, it's worth noting that by using FusionDebug, you don't need to enable CF's debugging output. Again, whether in production or simply on a server where you've not got control to get debugging turned on, this can be a valuable benefit.

You can change the value of variables on the fly during execution

Still another cool feature of step debuggers (in general) is that they permit you to change the values of variables within the code being debugged, such that on the fly, while the code is running, you can change the behavior of the app should you need to. This sort of thing can be easier than changing the code to effect that changed value (recall the previous point about how you may not even be able to edit the code to change a variable manually).

Sometimes a simple CFOUTPUT/CFDUMP will not suffice to solve a problem

Since we haven't shown how to use the tool, you'll also have to take this on faith: the features for viewing the current state of the application are also very powerful. While you're stopped at a breakpoint, you can view the value of ALL variables in ALL scopes. FD presents a very easy to use tree view to traverse and view the scopes. This also includes query resultsets (with still more unique features) and more.

And since you can view them all, you may be able to see information or make connections that you might not have thought to dump or output with traditional approaches.

You can use the debugger to understand the flow of execution of the request

Still another truly unique feature of a step debugger, that has nothing at all to do with outputting variables, is that they give you a clearly visual representation of the flow of a request. If you're ever wondering whether the code went into one IF statement or loop, or indeed if it included a file or called a custom tag or called a method in a CFC, these are all things that you can readily see in FusionDebug. Again, we haven't showed it in use yet, but we will in later entries see how it visually shows as you step from line to line or into nested tags, include files, custom tags, CFCs, and so on.

Further, the tool opens each such file as it is requested, so you may not even readily think of or see what files you would need to open if you did want to put manual debugging statements into them. That leads to one last point...

You can debug in situations where you don't even know where in a complex app to try to do CFOUTPUT or CFDUMP

That aforementioned feature of opening files as you step through them, and following the flow of execution, can be especially valuable in very complex applications. Let's consider (just as one example) a Model Glue application. When I run the modelgluesamples/legacysamples/contactmanager/index.cfm and view the files in the debugging output (showing all the files that were used to render the request, including CFM and CFC files and methods), there are nearly 150 shown. If something's amiss, you may be hard pressed to think where to begin.

For now, FusionDebug lacks something that the CF 4/5 debugger had that would make this last point especially valuable. That tool had a wildcard breakpoint, or what may be considered a conditional breakpoint: it would stop when a given condition was met. That's SO valuable. You can use it to find out when some condition arises (such as when some variable obtains or exceeds some value, or is set at all, or when some query exceeds a given executiontime--using cfquery.executiontime, and so on.) I have requested this latter feature of the FD team, and we can hope it may make it in the future. I have some other wishlist items which I will list in a future entry.

You can view the stack trace during execution

Following on to the previous point, while the traditional CF debugging output shows at the end of the page request what files were called to run the entire request, it doesn't really help you to know which were opened just to get a a particular point within a given template or CFC method. In FusionDebug, while you're sitting at a breakpoint, you will readily see the stack trace showing what files were opened to get to that point.

You can view the Java classes called to execute your code

Called the "java detail mode" in FusionDebug, it's an option which (if enabled) will show you all the java classes and methods called both to get to that point and which represent the kind of data in variables currently set. Indeed, if you double-click on a java class shown, it will show you any variables that were created from that object. For more info, including a screenshot with quick and easy explanations, see the FD site page for this feature.

Conclusion

That's a long list of reasons and benefits, and it's not even all of them. I just came up with these off the top of my head, wanting to help address the concerns of some who would dismiss the value of step debugging. There will surely be comments from folks on both sides of the fence (supporting it, dismissing it), and perhaps more info will be shared by others elsewhere. Let's get the conversation started.

So again, here is a summary of 13 things you can do with FusionDebug that I argue can't be done easily otherwise:

• can debug when a CFOUTPUT/CFDUMP may not be possible (CFCOMPONENT/CFFUNCTION OUTPUT=false, CFSILENT)
• can debug without having to rely on finding the output of CFLOG or CFTRACE (or enabling the latter)
• can debug requests from Flex, Ajax, or as web service
• can debug when someone besides the developer is calling a template
• can debug against production
• can debug on remote machine
• can debug without needing to change code
• can change the value of variables on the fly during execution
• can debug in situations where a simple CFOUTPUT/CFDUMP would not suffice
• can use the debugger to understand the flow of execution of the request
• can debug in situations where you don't even know where in a complex app to try to do CFOUTPUT or CFDUMP
• can view call stack during execution
• can view the Java classes called to execute your code

Note: This blog post is from 2006. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

Since the announcement of FusionDebug a couple weeks ago, there's been relatively little other news or blogging about it. I think that's a real shame and I'd like to address that here in a series of entries introducing you to it, and sharing tips and traps.

I've just given a talk tonight at the Atlanta CFUG (which I'm open to presenting to other groups via Breeze, if not on-site should I be traveling there for other reasons.

Over the next few entries here I'd like to share some of the points I did in the presentation. I'll cover such things as FusionDebug features and some gotchas to watch out for, as well as answer some frequent questions.

But I'd like to start with why I think people should be excited.

What is interactive (step) debugging?

What do we mean by interactive or step debugging? It's not about the debugging output at the bottom of a CFML page. Instead, it's about single-stepping through the code line at a time, while being able to watch the values of expressions and variables--and even change variables on the fly.

Where do you stand on using debugging?

Have you ever used an interactive (step) debugger? They are common in other languages (Java, .NET, Javascript, Flex, Flash, and more). Since many CFML developers have not used those, they may not even miss a debugger. Similarly, there are some who know about them and still are not excited about them. To each his own. I think that most will indeed find value once they've used it.

Many don't know it, but there was indeed interactive debugging in CFML in CF 4 and 5, by way of CF Studio (or now HomeSite+). In a future entry I will talk about how you can demonstrate and use that (with CF4 and 5 only). But Macromedia/Adobe chose not to carry that feature forward into CFMX, so FusionDebug represents the first and only current way to do step debugging in CFML for CFMX (6 and 7).

As a commercial product, you can also take consolation that it will indeed work as advertised and if it doesn't that there will be a company behind it to help support, improve, and evangelize it.

About FusionDebug

FusionDebug is an Eclipse plug-in. Just like FlexBuilder is a commercial plug-in on top of the free Eclipse framework, so too is FusionDebug a commercial plug-in on top of Eclipse. It's priced at US$ 299, with an available 10% discount code (CFCOMMUNITY) as well as volume discounts. There is also a free 20-day trial. Your first response may be that you don't think you should have to pay for such a product, but with no debugging tools seemingly on the horizon from Adobe, it's really a rather small price to pay if you will benefit from debugging.

Your second response, if you don't use Eclipse currently, may be to worry about having to use it. First, note that you don't need to give up your favorite CFML editor (DWMX, CF Studio, HomeSite+, CFEclipse, or whatever). Further, it's easy to learn how to use the minimal amount of Eclipse functionality you need to understand to use FusionDebug.

You do need to download Eclipse (which is free), unless you already have it installed (for instance, if you have FlexBuilder or CFEclipse). The FusionDebug User Guide explains how to get and install it (which is very easy).

It also requires just a minor change in the jvm.config file for the CFML server that you'll be debugging against (again, easy to do as well-documented in the User Guide). Here you indicate a port that the debugger will listen on, and you then do a minor setup in Eclipse to enable debugging against that server (again, well-documented and simple).

In the next entry, I'll actually introduce the features that FusionDebug enables. In the meantime, if you're too excited to wait, you can can read about the features, including screenshots, or you can even view some Captivate videos.

In future entries, I have several hidden gems and gotchas that I'll share.

Note: This blog post is from 2006. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

Wish you could simplify your captcha's? If you use Peter Farrell's Lyla Captcha, as I do because it's embedded in Ray's BlogCFC, I'll show a few quick changes you can make that will make them much easier for your users to read.

Sound counter-intuitive? Aren't captcha's supposed to be difficult to read, to hamper spammers? In my last entry, I made a call for simplifying captchas and why they aren't all bad. As a blog owner who uses them to weed out the random spambots who would otherwise clog my comments and feedback mechanisms, I like captchas, and I'm grateful for the work Peter's done.

That said, I have to admit that as I've encountered them in the blogs of others, I've grown a tad weary of their complexity. They require the user to type several characters and have several swirly ovals, random lines, and a wavy background. Frankly they're quite hard to read, and it would be a shame to lose commenters for that reason.

Again, the intent is to make it hard for some spammer to scan the captcha request somehow and figure out what's being requested so as to automate around it. Fair enough, but as I said in my last entry I'm really not that concerned about protecting my site from determined break-ins. I'm not a bank. I just want to keep out the automated pests.

With just a couple of changes to Lyla's captcha.xml file, you'll have a much simplified captcha, if you want one.

Lyla is highly customizable

On a lark, I decided to try to find out if Lyla might just be modifiable to dial down the intensity. Turns out it is, by simple changes in the lyla captcha.xml file, as documented in this PDF. Thanks again, Peter! :-)

After a few simple tweaks, I reduced my captcha to just asking for 3 characters, all lowercase, without all the swirly ovals, lines, and wavy background.

Changing Lyla's captcha.xml

In BlogCFC, the captcha.xml file is located in blog\client\includes (or just \includes if you've installed the blog client directory as your webroot.)

To effect the change I wanted, I ended up with the following values for the following entries. Again, see the docs for more info:

You can change them to suit your taste. Note that if you do change the randStrLen, the value selected represents the "average" length of the string that users will be asked to enter, and may vary by +/- 1 from that.

Make the changes, and check 'em out for yourself. Note that with Ray's BlogCFC, you need to reinitialize the blog (add ?reinit=1 to your blog URL) to see the changes. What I did was had one browser page open to do that, and another sitting on a blog comment form. After running the reinit, I could then just reload the comment page to see the impact. (If there's a still-simpler way to test changes to the captcha.xml, let me know.)

If you don't use BlogCFC, then you have to re-instantiate the captcha object after making changes to the XML file. If you've stored it in a shared scope (like application), you need to run some code that reloads it. Of course, restarting ColdFusion will also reload the CFC in whatever scope you stored it in.

Conclusion

Making these changes won't solve the accessibility problems some have with captchas, and it certainly could increase the risk of a determined spammer more easily breaking your captcha. As I said in the last entry, I doubt that's a real concern for most of us. If it proves to be so, then you can dial the intensity back up.

I just want to keep from annoying my readers, and I hope others will consider these changes to keep from annoying us all. :-)

PS: I do realize that one could skip the captcha graphic entirely and just go to prompting the user for a random string. That may just a bit "too" easy for a spambot to get around. To each his own.

Thanking Peter

One last note: while Peter certainly appreciates your kind comments (and do share them, as I'm sure many don't bother), those who REALLY appreciate his work should note that he gratefully accepts contributions by way of his Amazon Wishlist or you may may make a donation with PayPal, using his address, [email protected].

Note: This blog post is from 2006. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

Most by now understand what captchas are. Some love 'em, some hate 'em. I want to dial down the rhetoric some with this perspective: as a blog owner fighting frequent spam in comments and trackbacks, captchas (in some form, not necessarily a graphic) have their place to keep out spambots, and they can indeed be simplified (even the graphics ones) and at no loss of benefit. My bottom line: I don't use them as a double-key deadbolt lock to keep out intruders, I just use them as a screendoor to keep out random pests.

If you use Peter Farrell's Lyla Captcha, which I use because it's embedded in Ray's BlogCFC, in the next entry I'll show a few quick changes you could make in the Lyla captcha.xml file to make them much easier to read, going from this

to this
.

Before that, I just want to expand on those thoughts above on the general angst against captcha's, and why I think it's ok to make them easier to read.

The Haters

I realize that some have gone to great lengths to decry captchas primarily because they are not "accessible" (to those using screenreaders), though audio ones help solve that.

Others simply hate them because they're too darned difficult to read. I've surely seen that, even in the ones created by default in Lyla (thus my next entry on addressing that).

Now, while most use a graphic that a user must read, it's not the only approach. As the previous link discusses, other approaches include simpler approaches like asking the reader to add some numbers or answer a question (that only a human could reasonably do).

But the other complaint is that they give those who use them a false sense of security, because they can be easily broken, even the graphic ones.

But my Blog is Not a Bank

Here's the thing: my blog is not a bank. While the difficulty in breaking a captcha may be important to a bank or commercial site trying to use them for authentication, I just want to make it hard for an automated spambot to post crap in my blog comments and trackback forms. If you have any similar king of input form on a publicly accessible site, you may suffer similar problems.

I really can't believe anyone would go to the lengths of scanning and breaking the captcha on my site (random as it is) to get a crap spam comment into my lil' ol' blog. And some of the comments are just nonsense; it's not like they're trying to drive traffic to another site or something--so the popularity of my (or your) site isn't the issue. It's just the annoyance factor (both to me as I get notified of comments and to readers who would have to sift through them if I didn't delete them as I do now).

Having made the case for why a simpler captcha may suffice for some purposes, in the next entry I'll show how to control the degree of difficulty in reading them for captchas built using Lyla Captcha.

Note: This blog post is from 2006. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

If you've ever needed to know how long your CF instance has been running, did you know there's an incredibly simple solution? It's not really obvious, and in fact it may not work on trial editions of ColdFusion (for reasons explained below), but it's worked on the Enterprise and Developer editions that I and others have tested it.

Some may have noticed that there is a server.coldfusion.expiration variable (one of many read-only variables in the server scope, within the coldfusion structure). According to the docs, it's supposed to represent the date on which a trial edition of CF will expire.

But some have found (and I've confirmed) that on non-trial editions it instead reports the time that the server started. Try it youself:

It'll be a date, but is it in the future? or the past? Assuming it's the past, and you're not running on a trial edition, then it's likely the time your server had started. If you could restart your server and test again, you'll know for sure. :-)

Better formatting of the result

Now, if you want to easily determine how long the server has been up, just use the datediff function to report how many minutes there are between the time reported and the current time:

Now, that number will be in the thousands after only one day. If you just want to better format the number of minutes, you could use the numberformat function which (without any formatstring) simply adds commas where they would be appropriate:

But even better, you could use one of the nifty functions available at the cflib.org that could help present the result minutes in terms of days, hours, and minutes (duration()). Assuming you included the latter in your page, you could then output the value as:

I may put together a UDF to submit to the cflib to pull all this together, and which also checks if indeed the server being checked is a trial edition, etc. But I'll look forward to hearing people's feedback first.

Other options

Of course, it's worth pointing out that there are of course many tools that will monitor a server's uptime by watching it externally. It may also be possible to ask the operating system to report how long a given process or service has been running. I'll leave that for others to investigate.

Finally, I'll point out that there is indeed a tag in the Adobe Developers Exchange, CF_UpTimeMonger, that purports to help detect server uptime and says it works even for CF 4 and CF5. I have not explored it.

Note: This blog post is from 2006. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

Have you ever been annoyed when some web form (feedback page, blog comment field, or webforum) fails to properly convert your CFML or HTML so that it's displayed? Does it just disappear? Many know the solution is to convert the tag brackets to their equivalent character entities, > and <), but it's a hassle to do that manually! Last year I wrote about a free web-based tool in another blog of mine, tipicalcharlie.com, and as the challenge came up today on a CF list, I thought I'd point it out here:

http://www.tipicalcharlie.com/convert_markup_for_display.htm (Update: tipicalcharlie domain is no more, but page recovered using Archive.org.)

Note that this is not a tool you need to download and install; it's a hosted tool, just a simple but useful web form that converts whatever code you paste! You can then just copy the result and paste it into your desired form. Enjoy!

Note: This blog post is from 2006. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

Here's a blog entry from another site on a topic that I think some of you may enjoy very much:

"Don't miss out on the many powers of the Google Toolbar (some hidden buttons, some new context menu options, and more)"

http://www.tipicalcharlie.com/google_toolbar_1.htm (Update: tipicalcharlie domain is no more, but page recovered using Archive.org.)

Now, if you look closely at the URL, you'll see it's got my name in it. :-) And indeed, it's mine. I started the blog long before this one and in it I share all manner of tips related to computing (not CF-specifically).

I'm always torn about whether to post some topics here or there. I try not to cross-post much at all (and not even to blogs of other folks) unless it's something that I think you might really appreciate and otherwise miss. Such is the case here.

If you like the stuff there (see the categories, as there may be past entries you'd not want to miss), be sure to signup to receive new entries by email (as you can do here), or add it to your RSS reader of course. Not everyone uses them yet. Indeed, see the entry I did there on how to get notification by email of new entries from any blogger who may not offer their own email subscription feature.

(Update: Sadly, squeet (a tool to send RSS feeds by email) is no more. But there are other alternatives, that I track in a category of my CF411 site: http://www.cf411.com/rss_email.)

Note: This blog post is from 2006. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

Exactly one month after releasing Spry 1.2, the Adobe Spry team has responded to user feedback and also slipped in some new features in a new 1.3 preview release.

As part of my ongoing series on Spry, here's my take on what's new. The primary new feature set is "Spry Effects, for introducing animations and color effects to your pages." While it may sound like just eye candy, there are some useful things. More on that below.

There is also an interesting new 2-selects related demo (more below) and various new features to existing things, like new methods to manipulate the accordion, fixes to various aspects of the Ajax (SpryData.js) functionality, as well as support for new setup/finish callbacks for the effects. See the site/docs for more on those. Here, I want to highlight the 2-selects related demo and a brief discussion of the effects.

Nifty 2-selects related demo

One thing that's easily missed (not highlighted anywhere) which may appeal especially to CF developers is a new 2-selects-related demo, though they call it a "master detail" demo instead. It shows how to make 2 selects relates data between 2 datasets. The code is remarkably easy, as explained in the one paragraph there and shown in the few lines of code which you can see doing a "view source" there. Again, this is the beauty of Spry: those few lines of code in the browser are indeed all that you need to write, and all that the browser needs to execute.

For those new to Spry, note that the data can come from any file of XML data or template that generates it, as requested in a line of Javascript (the only javascript code you need to write on the page):

I'll also remind those new to Spry to check out all the entries in this series on Spry, as well as my Spry Compendium of resources to help get you started.

The new effect library

The Spry Effects are the following:

• Appear/Fade Makes an element appear or fade away
• Highlight Flashes a color as the background of an element
• BlindUp/BlindDown Simulates a window blind, up or down, where the contents of the affected elements stay in place
• SlideUp/SlideDown Simulates a window blind, where the contents of the affected element scroll accordingly
• Grow/Shrink Increases/reduces the size of the element
• Shake Moves the element slightly to the left, then to the right, repeatedly
• Squish Reduces the element to its top-left corner and disappears

Some will find more value in various aspects than others. Let's keep in mind that the focus for Spry is on non-technical HTML developers, to ease access to not just Ajax-style development but also the DHTML-based (CSS, Javascript, and HTML) visual components that often go along with those. A key point is that these changes in screen appearance happen without a browser refresh. An interesting point they make is the following:

As with previously-released Spry datasets and their accompanying widgets, we designed Spry effects to be easy to implement on the page while letting the framework do the real work. No new tags or strange syntaxes are required. Designers with a rudimentary understanding of JavaScript can easily implement any of these effects. More advanced users can combine base effects to create more complex and sophisticated effects.

The following shows an example of a basic effect :

onClick="Spry.Effect.AppearFade('target',{duration: 1000,from: 0,to: 100, toggle: true;});"

You can apply an effect to almost any page element, and the code is easy to understand and edit. With the trio of Spry framework features--datasets, widgets, and effects--Adobe hopes to provide designers and developers the tools they need to easily create Ajax-enabled pages.

Why Is Adobe Re-inventing the wheel on effects? Why not just use an existing library?

Sure, there are other libraries that do more, but at least Adobe is working to add more and more. In fact, some may wonder why they are bothering to create their own when there are those other packages. They now specifically address the question of why they don't just integrate with some existing library, like Scriptaculous, and instead are using them as a model while keeping focused on their own vision.

All that said, I could even see CFML folks taking ready advantage of things like the blind, shrink/grow, slide, and squish, such as to add online help on a page that appears and disappears. Again, sure, if you know how to do CSS and/or javascript yourself, you can do it yourself.

I must admit that when shown on this combo page, I'm left wondering how the slide and blind differ from each other (and even the accordion). :-) If you view the demo that works with images instead, the difference becomes more apparent.

The effects are enabled in a new .js file (SpryEffects.js), but beyond that and 3 others it's still quite a light-weight framework.

Other Comments

Note that they indicate in the readme that they've removed the docs from the download, and they are available now only online. Still, it seems most of it has just moved to an articles directory, and there are of course still the reamdme, changelog, and other HTML files in the download.

Finally, they do clarify (frequently) that this is pre-release software, so jump on board and be a part of making it happen--but have patience that things will change as they learn and evolve the product.

Note: This blog post is from 2006. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

If you try to use the Flex Builder CF Wizard, you may get tripped up by trying to deploy the resulting SWF (with its communication back to the CF Server) on a remote box (where that CF Server would live). It's easy enough to do, but it may fail to work, if you're not careful about how you configure things while running the wizard, to indicate that remote server URL. It was causing quite a bit of consternation for some, and finally Ken Reiss has observed the solution and blogged about it:

http://www.kenreiss.com/blog/index.cfm/2006/8/10/Flex-20-with-CFMX-702--SUCCESS

I just think this is something that others may trip over in the future and not find readily, so I want to point it out to those that I can.

Note: This blog post is from 2006. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

Folks often ask me whether I know if BlueDragon can run either of the two performance analysis tools, SeeFusion and FusionReactor. The answer is a qualified "yes". They will run (currently) on the J2EE edition of BlueDragon, but not the standalone editons, BlueDragon Server and Server JX.

Both SeeFusion and FusionReactor are based on an underlying java-based mechanism called Servlet filters. On the surface, it might seem that things should work since the standalone versions of BD are built atop ServletExec (just as CFMX standard and enterprise standalone editions are built atop JRun).

Sadly, the edition of ServletExec that New Atlanta chose to bundle under BD (a choice made a few years ago) does not support servlet filters. ServletExec itself has indeed supported servlet filters for a few years; it's just that New Atlanta never had any motivation to update the version that was underlying BlueDragon. Who knows if that may change in the upcoming BD 7.

The good news is that it seems you can indeed use both SeeFusion and FR with BD/J2EE. I've previously done the former, and my reading of the FR docs for now suggest it would work fine. The installer guide for FR has a section on "manually installing FR", and where it discusses the directories to be updated for working with Tomcat and Jboss, it's really the same info that would apply to BlueDragon deployed on those servers (or any like them). (I've tried it tonight and hit a snag, and the guys from FR are working with me to get through it. I'll update with a comment here whatever I find.)

Finally, of course, BD.NET doesn't support servlet filters at all, so you can't use SeeFusion or FusionReactor on that product.