Have you ever wondered if (or how) you can add an iframe to a Fireworks prototype? What about inserting a SWF? Or adding some jQuery functionality?

Well, I just finished reading a truly excellent article at the Adobe Developer Center, written by David Hogue and Mariano Ferrario that takes protyping with Fireworks to the next level.

The article shows you how to leverage CSS, JavaScript and HTML using Fireworks and Dreamweaver to create a highly interactive HTML prototype. There's a great synergistic result when you combine the design capabilities of Fireworks with the coding strength of Dreamweaver. 

If you're interested in prototyping, head on over to the Adobe Developer Center and check out this article.

Mastering CSS with Dreamweaver CS3, the book I co-wrote with Greg Rewis, is finally out. Yes, I know, it was long overdue. I took a picture of it when I finally got to see it at Greg's house (no, my copies haven't arrived yet), so if you'll excuse the exhausted, traipsing around Phoenix all day look on my face, you can see me with the book on Flickr.

Greg and I didn't want to create the same CSS or Dreamweaver book that others have written. Those books are published, are very useful, and if that's what you need buy the appropriate book. Our goal instead was to show how to create standards-based, accessible web layouts using Dreamweaver. It's a myth that you have to hand code to be a real web developer. Is it best to know how to semantically mark up your page? Yes, absolutely. This is a craft and you should know as much as you can about it. Can you hand code within the Dreamweaver environment? Of course you can -- I do it all the time. Do you have to? Absolutely not. There are tools within Dreamweaver that make your work faster, and more effective whether you're working in code or design view. If you haven't looked at Dreamweaver since about MX or so, it's come a long way baby!

Chapter 1 is an overall review of important CSS principles that you must understand to create sturdy CSS-based layouts. The project in chapter 3 takes a lovely, nested table-based layout and transforms it to a CSS layout. Each of the remaining four chapters are a full project based on the CSS layouts I wrote for Dreamweaver CS3 - Fixed, Liquid, Elastic and Hybrid. Chapter 6 also uses Spry 1.6 (an upgrade from Adobe Labs for the Spry 1.4 version that ships with Dreamweaver CS3) and takes you through the process of using HTML data sets to create an accessible Ajax gallery -- unobtrusive javascript and all. We hope the projects will feel like we're working with you as your personal trainer.

The book is full of CSS tips and techniques. It also teaches a variety of ways to use Dreamweaver CS3. Both Fireworks and Photoshop comps are used and the integration of those programs with Dreamweaver is illustrated.

Our hope is that the techniques taught in the book will make your beautiful designs more solid as well as making you more comfortable with the program used by so many web departments. I use Dreamweaver every day and even I learned some new Dreamweaver tips from Greg! Here's what one reader had to say:

"The first chapter alone was worth it to me. I have a lot of CSS books, tutorial sites, etc. Maybe I'm more familiar after working with it for a while, but for me, this book is as clear as a bell, informative as a book ought to be, and motivational as a hand grenade... made me want to jump up and run like hell... to Dreamweaver to try stuff out."

C. Lindauer

Some of you may have also heard a rumor about the other partnership that came out of writing this book. And to that I say, yes, it's true. Greg and I were engaged (via Twitter) in early March. You can think of the book as our baby. ;)

For anyone who knows me well, the most shocking part of this post is that I actually, finally, put my own web site up. Yes, after 2 years of "Coming Soon," I've actually launched my site focued on training, speaking and coding. One of the things I learned (which I knew, taught, but obviously wasn't practicing) is--let the content dictate the design. Oh my word--I had three designers work on the site over the past two years before I realized I should practice what I preach and let the content, semantically marked up, determine the design. So much better than trying to force the content into your preconceived design notion--at least when you'd like to accomplish something. Special thanks to Carolyn Wood (editor-in-chief of Digital Web and owner of Pixelingo) for all her hard work with me on this (and for continually kicking my butt)!

Meanwhile, something I found in the process of creating this site, I wanted to share with you guys. Due to the spam I receive on my blog and the form on my old site, I really wanted to make it more difficult for the bots. However, I'm also very concerned about accessibility with the current CAPTCHA products I'm aware of. Enter reCAPTCHA. This one actually gives the user the ability to interact with the CAPTCHA by viewing the image and typing it in--even with JavaScript turned of. And if they prefer, they can have the challenge spoken. I've not had the ability to have a non-sighted user test it, but it seemed to work well for me when listening to it. Best of all, it's free!

They have one other product which I'm also using -- Mailhide. You enter the email and they generate some code that you put into your page (I doctored mine a touch) and, in the same way, it forces the user to solve a reCAPTCHA challenge to get your email. Of course, I'm sure nothing is foolproof, but having a little protection is better than nothing at all. Have a look!

A web buddy has just hipped me to This.

See that item down in the left corner? Safari now has a shiny new version number, and it works on the PC too. So old Stevie has entered the PC Browser Wars, eh? That should stir the pot a bit.

In my last post, I complained about sites that pop up windows and take away my menu bar so I can't print. Tonight I found the perfect Firefox extension to stop this annoying scripting: Unhide Menubar. It keeps scripts from ever hiding the menu bar, ever. I've already put it to use to print out my flight confirmation through Orbitz.

Why do so many sites that insist on opening popup windows also insist on taking away my menu bar when they do so? Sometimes it makes sense, such as in my Yahoo Music player that pops up. But other times it seems to only be done for its own sake, and it's really annoying.

Last month was the annual enrollment period for health care spending accounts, dental insurance, vision insurance, and several other benefits programs offered by the State of North Carolina, which I work for. This year, they offered an online enrollment option for the first time. However, the web site they created solely for this purpose (they already have a couple other web sites, and I have no idea why they didn't make this new site simply part of the old sites...but I digress) was awful. The navigation was very unclear and hard to use.

When I went to enroll, the site insisted on popping up a new window with all of my toolbars stripped away, including the menu bar. Why? This didn't help me in any way that I could see. The enrollment process was just a series of forms and text-based pages — in short, nothing that couldn't be presented in a regular web page as part of the rest of the site. Perhaps they didn't want me to click any links other than the form buttons that navigated me through the enrollment process? If that was the case, why not just strip the nav menu out of the enrollment pages, and just leave me in the regular site?

I can handle a popup window, as much as it annoys me, as long as it doesn't hamper my work. This one, however, did. When I finally enrolled, I clicked on their printer-friendly version link. This opened another popup window. I expected it to automatically bring up a printer dialog box, since I couldn't access File > Print to do it myself. Instead, the new popup told me to hit the Print Screen button to print the page. But the PrtScn button doesn't actually print — it takes a screenshot! I had no way to print my page. Why had they decided to hide the menu bar from me? What harm would it have been to include it? What benefit did they get from it that was so important it was worth completely wrecking the user-experience for me and preventing me from printing?

Ironically, after I finished my enrollment, they presented me with a feedback form, "in order to ensure that www.ncflexonline.org provides the ability to meet your needs." However, the comment fields they provided only allowed 256 characters, which is only a couple sentences worth of comments, and not nearly enough to convey my dissatisfaction. I suggest that if they really want to create sites that meet their users' needs that they employ extensive usability testing before launching a site, instead of taking surveys afterwards that never appear to be acted on.

After this frustrating user experience, I went straight to userscripts.org to find a Greasemonkey script to override all those sites that try to take my menu bar away from me. Alas, no such script exists on this site. I beg someone to write one and let me know about it! Or, if anyone knows any other tricks to get the menu bar, or other toolbars, back, please let me know that as well! 

In light of sharing this information quickly, I'm going to tell you the story of a little bug without a demo. (The site I'm working on is still NDA, so I can't illustrate it with that either.) I'll try to get one up soon.

The Backstory

This site is using the new version of Nifty Corners (Nifty Corners Cube). It's a simple little javascript solution to rounded corners. You write the CSS selectors for the various elements, add a bit of javascript in the head of the document, and you have rounded corners. If javascript is disabled, you have square corners. Graceful degradation.

I had worked most bugs out of the site and started testing outside Firefox (which I develop in) and IE PC (which typically has the most bugs). When I opened one of the pages in Safari, I was met with quite a surprise. Nearly all the links on the page were glowing a bright red. Perhaps it didn't actually glow, but when you're expecting a deep blue, it seems so. Well, what the heck!?

The Search

Obviously, my first thought was that I had something funky going on in the cascade. (There are some admin-only links in this site that are red.) In Dreamweaver, I clicked into one of the link headings. Using the Rules pane of the CSS styles panel, I started going up through the cascade. Nary a red link defined there. Hmmmm...

I commented the admin link completely out anyway -- just in case. Nada. Nothing. No change.

This is when Google is your friend. I googled and found a post where someone was reporting exactly the same thing. My old friend Philippe Wittenbergh found that the person reporting the problem had a couple missing CSS files linked in the head of their document. The 404 page (which of course, you don't actually see) has red links defined in the head. This selector was mistakenly overriding the links defined in the user's stylesheet. AHA! I've got it now!

I opened the remote side of the Files panel in DW and checked to be sure all the documents in the head were in the correct directories. They were. Hmmmmm...

It was late. My brain was dead. I went to sleep with visions of browser bugs dancing in my head.

The Solution

I was going to go back to the remaining bugs later since I had other things to work on as well. I'm betting though that some of you can relate to getting a bit obsessive about a bug. I WILL smash this thing!

I was asking my friend, Vicki Berry Stanton, if she'd ever seen this one. As I went through the things I'd found, the steps I'd taken, and how I'd bombed out fixing it so far, I got an idea. (Isn't that how it usually works when you're stymied?) Using the Web Developer's Toolbar in Firefox (undoubtedly my favorite Firefox extension), I hit Cmd/Shft/C (or CSS > View CSS) to view all the style sheets linked to this XHTML document. When I got to the bottom of the results page, A 404 ERROR! Pardon me for shouting, but for once, I was pretty excited to see that error.

The odd thing was that the stylesheet referenced in the 404 didn't exist on my page. It was a second link to the niftycube.css and was not linked to the directory it should have been. Hmmmmm again... Where in the world was this invisible link coming from?

And then the light bulb came on. Sunuvagun! I opened the niftycube.js file and, sure enough, there was the code. The javascript was pulling the CSS file into the document and had defined it in the root of the site. The old version of Nifty Corners required you to place a link in the head to the Nifty CSS document. But evidently, the new one does not. This is what happens when site development takes so long that a newer version of the technology you're using comes out and you have adapt to a changed way of implementing it. I changed the link in the javascript to the proper directory, removed the CSS link in the head, and like magic - blue links!

The Story has a Moral

• If you run into unexpected red text links in Safari, first check for any CSS documents that might be missing or mislinked. The 404 page will override your defined colors.
• If you're using the new Nifty Corners Cube, you don't need to add a link to the CSS file like you did for the older Nifty Corners. But make sure that the link in the javascript is using the proper path to your file.
• For every bug the browsers bring, there's a shoe big enough to squash it!

Explanation... or Theory

A couple people have asked me if I know why this is happening. I do have a theory so I'm adding this amendment. My belief is that Safari is not validating that a document that is linked as CSS is actually CSS data. So, in the case of this bug, when Safari encounters the 404 HTML page instead of the CSS page that should be linked, it is parsing it as if it's CSS anyway. Thus, it renders any styles defined there in addition to the ones you have defined in your stylesheet. Including the lovely red links. You may, in fact, find other anomalies depending on what your 404 contains. I'm sure Safari is aware, but I'll check to be sure it's reported tomorrow.

One of the web design trends I've noticed over the past several months is to make text or graphics appear to be reflected, as if there is a piece of glass that they are sitting on. I've started tagging sites that I come across that exhibit this graphic effect, and you can see the beginning of my collection at http://del.icio.us/pixelsurge/reflective.

Today I found a Javascript that will generate the reflections for you. I haven't used it, but it looks pretty slick. If you're dying to get in on this reflective trend, try the reflection.js script out.

For those of you that have been following the development of, or even using sIFR, this post is for you. Mark Wubben has announced the release of the alpha of the next version of sIFR. I just got back from TODCon, so I haven't had time to play with it yet, but the feature list makes it look very promising. Especially the part about the increased simplicity of tuning your fonts. For me that was the only difficult part.

Other interesting bits -- Mark is taking advantage of the new Flash 8 filter features, like drop shadows. You'll also get the added benefit of Flash's new anti-aliasing and leading. There's also a fix included for the AdBlock issue. All in all, very promising.

If you've got time to test/play/help make this version the best it can be, head over to the sIFR 3 Alpha page and download it now.

Part 1 of this post showed the server-side code for a browser resize tracker. This part will show the client-side script. This can go on any type of page -- php, coldfusion, html, etc. The scripts consist of several functions:

• getBrowserSize() -- called in the onload and onresize event to capture the browser size and pass to the server-side page
• getSize() -- gets the size of the browser window
• passFields() -- takes an array of fields (fieldname, value, fieldname, value, etc) and a URL and passes the fields to the URL as querystring variables
• resetSizeTimer() -- creates a timer so that when the browser is resized, only one event is recorded (browser resizing typically fires the onResize event numerous times in succession.)

In addition, we set a global variable to act as a flag for the resize timer. The code is pretty straightforward, and can be placed in the head of any file:

<script>
var size_timer = false;

// Subroutine to get the size of the window
function getSize() {
 var myWidth = 0, myHeight = 0;
 if(typeof(window.innerWidth) == 'number') {
  //Non-IE
  myWidth = window.innerWidth;
  myHeight = window.innerHeight;
 }else if(document.documentElement &&
  (document.documentElement.clientWidth || document.documentElement.clientHeight)) {
  //IE 6+ in 'standards compliant mode'
  myWidth = document.documentElement.clientWidth;
  myHeight = document.documentElement.clientHeight;
 } else if(document.body && (document.body.clientWidth || document.body.clientHeight)) {
  //IE 4 compatible
  myWidth = document.body.clientWidth;
  myHeight = document.body.clientHeight;
 }
 return [myWidth, myHeight];
}

// Pass fields to server given a URL and fields in name/value pairs
function passFields(url,args) {
 url += "?";
 for(var i=0; i<args.length; i=i+2) {
  url += args[i] + "=" + args[i+1] + "&";
 }
 //Set up the AJAX communication
 if (window.XMLHttpRequest) {
  req = new XMLHttpRequest();
 } else if (window.ActiveXObject) {
  req = new ActiveXObject("Microsoft.XMLHTTP");
 }
 try {
  // Pass the URL to the server
  req.open("GET", url, true);
  req.send(null);
 }catch(e) {
 //nothing;
 }
}
function resetSizeTimer() {
 size_timer = false;
}

// Get the size and pass to the server
function getBrowserSize() {
 if(size_timer)return;
 size_timer = true;
 self.setTimeout('resetSizeTimer()',1000);
 var theArray = getSize();
 var url = "getBrowserSize.php";
 var args = new Array();
 args.push("width");
 args.push(theArray[0]);
 args.push("height");
 args.push(theArray[1]);
 args.push("screenwidth");
 args.push(screen.width);
 args.push("screenheight");
 args.push(screen.height);
 args.push("pagename");
 args.push(window.location);
 passFields(url, args);
}

</script>

All you need to do is to add the getBrowserSize() function to the onload and onresize events of the <body> tag:

<body onload="getBrowserSize();" onresize="getBrowserSize();">

Now, when you browse the page, the server records the browser size upon load and upon resize. Typical information would look like this:

The technique is handy and can be used for any other situation where you need to pass client-side information to the server.

Cross posted at Tom-Muck.com

It's always interesting to find out about viewing habits of web visitors. One of the things that is hard to determine when building a web page is how big to make your pages. Do you assume the user has 1280x1024? Do you assume 800x600? Do you assume that the user will have a fully maximized browser? One way to find out this information is to read the properties via JavaScript and store them. AJAX gives a web developer a valuble tool that allows the server to communicate with the browser in real time based on client-side events (such as resizing). I wrote a little script that I can insert on a page to track the resizing made by a user in relation to his screen resolution. After getting this information from a variety of users, I can run queries on the data and get some insight into browsing habits and adjust my page designs accordingly (or have them adjusted by a designer, in my case.) The code will be presented for ColdFusion and PHP.

First, I create a table in my database to store the information. The following is for SQL Server:

CREATE TABLE BrowserSize (
 browsersize_id int IDENTITY (1, 1) NOT NULL ,
 browsersize_width int NULL ,
 browsersize_height int NULL ,
 browsersize_screenwidth int NULL ,
 browsersize_screenheight int NULL ,
 IP varchar (50) NULL ,
 pagename varchar (255) NULL
)

The following is the equivalent for MySQL:

CREATE TABLE BrowserSize (
 browsersize_id int AUTO_INCREMENT PRIMARY KEY NOT NULL ,
 browsersize_width int NULL ,
 browsersize_height int NULL ,
 browsersize_screenwidth int NULL ,
 browsersize_screenheight int NULL ,
 IP varchar (50) NULL ,
 pagename varchar (255) NULL
);

You could also add a timestamp field, if you want to track times.

Next, I create a server-side page to grab the information and pass it to the database. The information will be passed in the URL. The code is self-explanatory. Basically, we pass width, height, screenwidth, screenheight, and page location in the URL, and insert it into our database table, along with the IP address of the user. The following is for ColdFusion:

<cfparam name="url.width" default=0>
<cfparam name="url.height" default=0>
<cfparam name="url.screenwidth" default=0>
<cfparam name="url.screenheight" default=0>
<cfparam name="url.pagename" default="">
<cfset url.width = val(url.width)>
<cfset url.height = val(url.height)>
<cfset url.screenwidth = val(url.screenwidth)>
<cfset url.screenheight = val(url.screenheight)>
<cfset ip = cgi.REMOTE_ADDR>

<cftry>
<cfquery datasource="yourdsn">
INSERT INTO browserSize
(browsersize_width
, browsersize_height
, browsersize_screenwidth
, browsersize_screenheight
, IP
, pagename)
VALUES
(#url.width#
,#url.height#
,#url.screenwidth#
,#url.screenheight#
,'#ip#'
,'#url.pagename#')
</cfquery>
<cfcatch>
<!--- do nothing --->
</cfcatch>
</cftry>

The following is for PHP:

<?php
$_GET["width"] = isset($_GET["width"]) ? intval($_GET["width"]) : 0;
$_GET["height"] = isset($_GET["height"]) ? intval($_GET["height"]) : 0;
$_GET["screenwidth"] = isset($_GET["screenwidth"]) ? intval($_GET["screenwidth"]) : 0;
$_GET["screenheight"] = isset($_GET["screenheight"]) ? intval($_GET["screenheight"]) : 0;
$pagename = isset($_GET['pagename']) ? $_GET['pagename'] : "";
$ip = isset($_SERVER['REMOTE_ADDR']) ? $_SERVER['REMOTE_ADDR'] : "";

$conn = mysql_connect("localhost", "username", "password");
$query_rs = sprintf("INSERT INTO browserSize
(browsersize_width
, browsersize_height
, browsersize_screenwidth
, browsersize_screenheight
, IP
, pagename)
VALUES (%s, %s, %s, %s, '%s', '%s')"
,$_GET["width"]
,$_GET["height"]
,$_GET["screenwidth"]
,$_GET["screenheight"]
,$ip
,$pagename);
mysql_select_db("cwtest");
$rs = mysql_query($query_rs);
?>

Both of the pages can be run in the browser to test (saved as getBrowserSize.cfm and getBrowserSize.php respectively). If the values of 0 are inserted in the database, everything is working. I'll post the client-side AJAX code in Part 2.

Yes, admittedly, I hate pop-ups. I surf with my pop-up blockers enabled in both Firefox and Safari. If they somehow get around my blocking them, I immediately close them. I never click on advertisements. So I'm not really any different than you.

Today however, I was going to a site my husband gets a newsletter from to check a business article. Interestingly, they had this cute little yellow sticky note-looking thing that welcomes you to the site and offers a trial to their daily newsletter. What's so cool about a sticky note, right? Well, this sticky note is different. It sits at the mid-top of the page and overlaps their navigation. It has a nice little drop shadow that you can see through. It has an X in the top right corner so that you can close it, or you can click the sticky note and go straight to the offer. Pretty unobtrusive and well-done in my opinion. I found, by digging through the Early to Rise code that the service is provided by a company called Instant Attention (I am not in any way affiliated with them ;)). The little note can be put anywhere on the page, has different handwriting fonts you can choose and grows and shrinks based on the amount of content it contains. It gets around all pop-up blockers, however, since it's based on JavaScript, it obviously won't work with JS disabled.

So why does this one not bother me? I think it's because usually, a pop-up is advertising something for another company. Something I'm not interested in at all. This is instead an offer from the web site I'm visiting. Now that's something I might be interested in. And if I'm not, it's just a handwritten note that I can close right up. It has me thinking about how some of my clients could possibly benefit from such a widget. Hmmmm...

I really thought we were done with this. At least I thought that larger, more professional sites had changed. Browser sniffing. Locking people out of web sites due to their browser choice. What happened to presenting an unstyled page to those who choose a more current browser? What about screen readers?

Case in point -- National Geographic. As some of you know, I home school my sons. This morning, I was helping the eldest with some Grasslands research for Biology class. I Googled what appeared to be a great link. However, when I hit it, this is what I got:

Your Browser is not supported

The Following Browsers are supported:
Please download one of these free browsers and try again.

Netscape 4
Netscape 6
Internet Explorer 4
Internet Explorer 5
Internet Explorer 5.5
Internet Explorer 6

So rather than telling me my experience would be better if I were using one of these icky browsers, they choose to completely lock me out. Ahhh, but I'm one of those smart web developer types, right? So I just go to my little Web Developer's Toolbar, and I turn off JavaScript. They can't sniff without it! Now I'm all set to read. I refresh my page and voila! I have nothing. I have a completely and totally white page. Okay...

Final ditch effort. View Source. Wow -- the whole, entire, freaking page is loaded with JavaScript. There is no page without it. So they sniff and then they load. If they can't sniff, they don't load anything.

Yes, I have access to a PC. And yes, I went to the page and know that the main portion is an "interactive" map -- albeit a very slow clunky one. I wonder if they actually tested it in Moz-based browsers before they locked everyone except IE and NN out. Perhaps, they could allow the rest of the page to load? Maybe I'd like to see and use the sidebars, even if they've created something in the main area that no browser but IE and NN can handle? That would be swell.

I have to say that I'm impressed. Last night when I got home from Volleyball (yes, we won both matches, thank you ;)), a friend pinged me to talk about AJAX (Asynchronous JavaScript and XML). As I always tell people when I talk about sIFR, "I am not the JavaScript guru," but man, maybe I should be. The recent methods being used open up a whole new world of possibilities for web page interactivity. (No, I won't get into the criticism here.)

Take the new MXNA 2.0 as an example. Though they had done some cool AJAX stuff with the reports already, Christian and Mike have really outdone themselves with their proof of concept using the MXNA 2.0 Category Feed Reports. Click on a category on the right -- like Dreamweaver -- watch as the feeds below load without your page reloading. Now click on a feed, like CMXtraneous, and watch how the chart simply morphs into the new feed. See how the posts below it change? Did you notice that you never once reloaded the page? How sexy is that?

Christian explains better than I, "...notice how both the Flash chart and the posts below the chart update without the page refreshing. When you click on a feed name, we're using JavaScript to pass data into the Flash movie which then updates itself using the MXNA web services. When you click on a bar in the chart, we pass data from the Flash chart into JavaScript to load the selected post at the top of the list." Wow.

It's a new sphere of Flash/AJAX interaction and it can lead to some exciting possibilities. As Flash and JavaScript uses continue to evolve, it makes me wonder what I'm missing. Looks like it might be time to expand my skills yet again. (Do we ever know enough?)

The thing we've all been waiting for, the final release of sIFR, has finally arrived! Well, it's the thing I've been waiting for anyway. ;) And the release was while I was at TODCon in Las Vegas. Thus my delay in letting you guys know.

The new tweaks they've added are great. Mark and Mike even gave me something I requested a couple weeks ago -- the ability to use comma delimited selectors in the JS replacement calls. That's nifty! The Flash Block extension problems are worked out. They smashed a couple Safari bugs at the last minute. I was doing a session at TODCon on sIFR so they burned some midnight oil to get final files ready for me to use and distribute. These guys truly rock!

And now, due to their updated and excellent documentation, it's time for you guys to take this to your clients. It's time to rock the web with some new typography. I'll be adding sIFR to a large client site this week (I'll post the URL here when it's completed). I can't wait to really jazz things up. Pop over to the main sIFR page or Mike's blog entry about sIFR. There's also the wiki -- a useful place for you to leave tips and info for other developers as you use sIFR (with links to other sIFR resources as well). And finally, there's the sIFR forum -- just in case you need to ask a couple questions.

I'd love to see some of the things you do with sIFR, so leave me a comment or drop me a line at CMX.

In my article titled Communicating with the Server without Reloading the Page, I used a free temperature web service to show how the XmlHttpRequest object worked in JavaScript.  Even though this service has been active for a couple years now, I should have known better.  Merely two weeks after my article was published; they took the web service down.

They did however put up a static replacement.  Instead of returning the current temperature of the zip code you provide, the service always returns a static temperature without doing a lookup.  But all is not lost, the point of the article is not how to get the temperature of a given location; it is how to do so without reloading the page.

While it's deprecated, dreamweaver.popupCommand() is used in several places within Dreamweaver, it isn't documented as that method that is supposed to be replacing it, dreamweaver.runCommand(). In the documentation for dw.runCommand() it states that you can pass in option arguments that will be procesed by the receiveArguments() function within the called Command. dw.popupCommand() also can take optional parameters to pass on to the called Command. For example, if you wanted to pass along a first name, last name, and age of a user to a Command, you could use the following code:

dw.popupCommand('MyCoolCommand.htm','Bill', 'Horvath', 97);

Again, this method has apparently been deprecated since Dreamweaver 3, but its still around, at least through Dreamweaver MX 2004, 4 versions later.

Many times you'll need access to similar messages that you present to the user, whether in alerts for errors, or in notes on dialogs in a Dreamweaver extension. You could include the same text over and over again, in all of the extensions you have as part of your project, or you could write your own custom file manipulation functions that would share a common file to store your common text. Well, the great folks that bring you Dreamweaver also thought of this second method, they just happened to not document it just yet, and it's called dreamweaver.loadString().

Essentially, the loadString method takes as a parameter, an identifying ID that identifies the particular string that you're trying to use within your extension. Well, what does that mean? Ok, here's a code snippet to test out using Tom's JavaScript Eval panel:

alert(dw.loadString('General/docEncoding'));

On my system, I get alerted: iso-8859-1

So, where, and how do you store your strings so that that you can load them when needed?

As usual, you need to get into the Dreamweaver configuration folder. Go to the Configuration/Strings/ folder. You store your data in a specially formatted XML file. See the following code for an example of the format:

<strings>
  <string id="uniqueIdentifier" value="string to store">
</strings>

You can have multiple <string> tags within the parent <strings> tag.

Make sure that you uniquely identify your strings, preferably by "scoping" the strings by including your company name, or your initials, and also save your strings XML file with a unique name inside the Strings folder. All this is to avoid any naming conflict with other developers, or with built in stings, and strings XML files.

It's good for search engines and it's good for accessible beauty. If you're bored with the same old fonts, be sure to give sIFR a whirl. Mike Industries has released Release Candidate 4 -- it's getting closer to final all the time due to Mark Wubben's (yes, he's about 18) tireless work on tweaking the javascript. This time, they've disabled IE Mac (since it's so quirky) and given instructions on reenabling if you desire. There's better transparency and selector support in this version as well. They've also given us access to some cool add-ons like, preference manager and rollback (for style switchers). More info is available in The sIFR wiki. The wiki has lots of other good info, so use it or the new forums to stay apprised of the newest info.

So hurry over and download sIFR today. :)

If you work with SWFs in your extensions, you may want to be able to determine the dimensions of the SWF so you can generate the proper HTML code. Dreamweaver has a built in object called SWFFile that has a method getNaturalSize() that is supposed to return an array that contains the width and height of the SWF. However, if there are times when you won't get an array back. It seems that if the SWF was published as a compressed movie, then you get a null returned rather than the dimensions array. So if you depend on user supplied SWFs, you won't be able to rely on SWFFile.getNaturalSize() to allow you to generate the proper dimensions for use in your code.

I had seen a question in the Dreamweaver Extension forums a while ago and found out that compressed SWFs and SWFs created by Dreamweaver's Flash Elements seemed to cause the null return rather than the SWF dimension array. Thanks to Drew McLellan who ran into this issue on a new extension he's working on for bringing up this issue again, and inspiring me to find a way around the issue so that you don't need to find out the dimensions, you let Dreamweaver do it for you automatically.

So, what can you do to get around it? Well, you may think that looking in the Flash object on the Insert bar may give you some guidance, as when you use it, you end up with code on your page that has the proper dimensions for the SWF file in it. However, you'd be a little miffed checking the code in that the object itself doesn't do that, Dreamweaver seemingly performs some magic in the background after the Flash SWF code is added to the page. The code the Flash object generates sets the dimensions to 32x32, and immediately after the insertion, Dreamweaver somehow makes the changes to the code reading in the proper dimensions and setting them in the code.

So with this in mind you might follow along with the logic of an object that inserts code into a page and attempt to use dom.insertHTML() to place the code into your page. Again, you'd be stymied, as that doesn't seem to trigger the resetting of the SWF's code by Dreamweaver. Ok, if you're like me, you carry on with thinking through the problem, so if an object can do this, can I call an Object file to do the code insert for me? The answer to that would be: "yes...but". You can invoke an Object from your extension using dom.insertObject() passing in the name of the object file to run (minus the file extension). The "but" part of the answer is that you need to use the objectTag() type of Object to insert code into your page, as the insertObject() type of Object forces you to use dom.insertHTML() or some other method of code insertion. Doing with insertObject() causes Dreamweaver to do the replacement for you immediately after the code is inserted into the page.

So you have a workable solution, but you may need to be able to pass along the path to the SWF file to your Object that inserts your SWF code for you. Unfortunately dom.insertObject() doesn't allow for passing of parameters as dw.runCommand() and dwscripts.callCommand() do. So one way around this would be to attach a new property to the MM global object, say MM.my_flash_path, and then in the object take that value, and use it in the creation of the code to insert into the page.

Create an extension, and use whatever code you need to to get the path to a SWF file, then call dom.insertObject() and pass in the name of your Object. The following code just uses a default document relative path to the SWF, and calls an Object whose file name is blankFlash.htm. It doesn't matter which folder within the Object folder your Object resides, as long as it is named uniquely.

MM.my_flash_path = 'batang.swf';
var dom = dw.getDocumentDOM();
dom.insertObject('blankFlash');

Within your Object file, in this case blankFlash.htm, create an objectTag() function and pull the value out of MM.my_flash_path and create the code to insert your Object. See the following code as an example (:

function objectTag(){
  var flashFilePath = MM.my_flash_path;
  rtnStr = '<OBJECT CLASSID="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"' +
' CODEBASE="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,29,0" WIDTH="32" HEIGHT="32">\n' +
'<PARAM NAME="movie" VALUE="' + flashFilePath + '"> <PARAM NAME="quality" VALUE="high">\n' +
'<EMBED SRC="' + flashFilePath +
'" quality="high" PLUGINSPAGE="http://www.macromedia.com/go/getflashplayer" ' +
'TYPE="application/x-shockwave-flash" WIDTH="32" HEIGHT="32">'+
'</EMBED></OBJECT>';

  MM.my_flash_path = ';
  return rtnStr;
}

As you can see, the height and width are each set to 32, but when the Object is run, it will insert the code and Dreamweaver will automatically change those values to the proper ones. Plus, Dreamweaver will insert the code using your code tag and attribute case settings, so you'll get lower case tags and attributes if that's what you have set in your preferences.

Interestingly, if you try to just insert the <object> code and leave off the <embed> Dreamweaver will not perform the conversion. If you just insert the <embed> tag and no <object> wrapping tag, Dreamweaver will do the proper modifications.

Note: Your Object will be displayed in the Insert bar and be clickable, so you'll need to find some way around this if you only want to only be able to use your SWF code object through your extensions, such as checking for the MM.my_flash_path value in canInsertObject() prior to allowing the Object to run. Generally, you can include <!-- MENU-LOCATION=NONE --> at the top of your extension file to prevent it from being listed in the menus, and it does stop an object from being listed in the Objects panel, however, if you attempt to invoke an object with dom.insertObject() and it has the menu hiding code in it, you'l get an error popped up by Dreamweaver.