A question in the friends of ED forum from a reader of The Essential Guide to Dreamweaver CS3 with CSS, Ajax, and PHP has alerted me to a change in the way Spry 1.6 handles HTML tags in CDATA sections of an XML file. This results in most of the examples in Chapters 19 & 20 breaking after you upgrade to Spry 1.6. Fortunately, the remedy is simple. You can find the details on the book’s updates page.
Add comment January 6th, 2008
It seems as though the cause of the European clock change crashes on Dreamweaver CS3 is a corrupted file called WinFileCache-[random_numbers].dat. On Windows XP, it’s located at C:\Documents and Settings\<username>\Application Data\Adobe\Dreamweaver 9\Configuration. On Vista, it’s at C:\Users\<username>\AppData\Roaming\Adobe\Dreamweaver 9\Configuration. Simply delete the file and restart Dreamweaver. This still hasn’t been confirmed as the definitive solution, but it seems to work on most systems. It certainly fixed the problem for me.
[Update]: This has now been confirmed as the solution. Dreamweaver creates a new version of the file as soon as you relaunch the program.
23 comments October 29th, 2007
The Dreamweaver forums have been ablaze with reports of simple PHP and ASP code causing Dreamweaver CS3 to crash. I have tested many of the sample code snippets, and can confirm that CS3 is crashing on Windows XP and Vista, but not on Mac OS X. It also affects the PHP code in my books.
The cause of the crashes appears to be the clock change following the end of summer time in Europe. Since the United States is still on daylight saving time until 4 November, American users have reported that they are crash-free—for the time being, at least. It’s not clear whether it’s an Adobe bug or one caused by the Windows operating system, but there’s little point getting into the blame game. What’s needed is a fix—and quickly.
The temporary solution appears to be to change your system clock back to any time before 2 am on 28 October. Alternatively, use Dreamweaver 8.0.2, which isn’t affected. Neither solution is ideal, but Adobe has been alerted to the problem, and hopefully a permanent solution can be found soon.
[Update]: The solution is to delete WinFileCache-********.dat, which was apparently corrupted by the clock change.
5 comments October 29th, 2007
One of the nice things about being an author of books about PHP and Dreamweaver is that I get an opportunity to talk directly to the software development team. Devin Fernandez, one of the Dreamweaver product managers, dropped into London today on his way from Adobe MAX to a meeting with the former InterAKT Team (now Adobe Systems Romania) in Bucharest. We met for lunch, and for several hours he gave me an exclusive insight into how he and Adobe see the future of the Web and Dreamweaver in particular. That’s the nice part… However, it goes without saying that he wouldn’t have told me anything if he knew I’d spill the beans in my blog. Still, there are things that I can say without breaking the confidential nature of our discussions.
A major focus at MAX in Chicago was on Adobe’s plans for Flex and AIR (Adobe Integrated Runtime). If you’re unfamiliar with these two, they’re at the forefront of what Adobe calls Rich Internet Applications (RIAs). Flex is based on Flash and ActionScript, but makes it a lot easier for non-programmers to build highly interactive forms and online catalogues without the need for complex back-end programming. AIR is closely integrated with Flex and, in a nutshell, lets you build applications that run directly on the desktop outside a web browser. AIR applications are capable of communicating both with the local file system and with remote data sources across the internet. So for example, you can build simple widgets to display the local weather, or more sophisticated applications to search your hard drive for MP3 files and play your favourite music.
With all the razzmatazz surrounding Flex and AIR, not to mention a new project codenamed Thermo, you might be forgiven thinking that Dreamweaver’s days are over. Think again… Dreamweaver is Adobe’s flagship editor for (X)HTML, CSS, and JavaScript, which remain the core technologies underpinning most of the Web today, and which are unlikely to go away in a hurry. Devin estimates that there are perhaps as many as 4.5 million people using Dreamweaver in one way or another. They’re important to Adobe, and the Dreamweaver team is determined to keep the program fresh and vital to their needs.
The difficulty is how to do that. Dreamweaver users tend to fall into two broad categories with divergent interests and needs. On the one hand, there are individual developers and web designers, who either work entirely on their own or in small groups. They need Dreamweaver to perform a wide range of functions, and their priority is ease of use. On the other hand, Dreamweaver is also used by production studios, where a large team splits up the work according to each individual’s speciality. The specialists all want improvements in their own particular area. Programmers want better code hinting and introspection. Designers want better integration with Fireworks, Photoshop, and Illustrator. And everyone wants adherence to standards.
The impression I got from Devin is that the Dreamweaver team is aware of these demands, and has what it hopes will be some pleasant surprises up its sleeve when the wraps are finally taken off the next version of the program. When will that be? That’s always a secret that even authors aren’t let in on (which is why there’s often a delay of several months between a new version and the books to go with it). However, most software companies work on an 18- to 24-month development cycle, so I’m hoping that I’ve still got plenty of time before I need to start pounding away at the keyboard for my next Dreamweaver book.
One final thought… and something that might have slipped your notice in the coverage of MAX. Although much of the focus was on Flex, if you visit the AIR site on Adobe Labs, it says “Adobe AIR lets developers use their existing web development skills in HTML, Ajax, Flash and Flex to build and deploy rich internet applications to the desktop”. Notice that: HTML and Ajax (JavaScript) are listed first, a sure sign that Dreamweaver’s unlikely to be put on the back burner for a very long time to come.
It was a glorious sunny day in central London—definitely something in the air to put a spring into my step. 
2 comments October 5th, 2007
At long last, Adobe has created an extension to update the version of Spry in Dreamweaver CS3. You can download the extension by going to the Spry section of Adobe Labs. The extension is free, but to obtain it, you need to log into Labs using your Adobe ID. If you don’t already have an Adobe ID, it’s easy to create an account (also free).
Use the Extension Manager to install the Spry Updater for Dreamweaver CS3. When you first launch Dreamweaver after installation, you’ll be presented with a dialog box explaining how the updater works. It lets you update the Spry library files on existing sites, and gives you the option to replace all files or just those that you want to change. And if anything goes wrong, you can retrieve the old files from a backup folder.
The extension updates the Spry files to version 1.6 (the version that shipped with CS3 was 1.4), and adds code hints for the new features. However it does not add any new features to the Dreamweaver interface. To use the new features in Spry 1.6, you need to hand-code them yourself.
15 comments October 2nd, 2007
Adobe has taken the unusual step of revealing the first details of the next version of Dreamweaver less than six months after the release of current version (Dreamweaver CS3). Now, before you get too excited, the Adobe announcement says nothing about new features. Instead, it tells you what’s being taken out.
Among items destined for the chop are the much-maligned Layout Mode and Timelines. These are both sensible decisions. Layout Mode was a well intentioned attempt to make it easy for graphic designers to lay out web pages in the same way as desktop publishing. The problem is that it creates horrendous spaghetti code behind the scenes, and frequently results in cries for help in online forums. If you get your design right the first time, the code is normally stable; but as soon as you start to change things round—and who’s ever come across a graphic designer satisfied with a first attempt at layout?—the page often falls apart like a house of cards. Timelines equally rely on outdated code, and animations are much better left to Flash, so it’s good to see them finally on the way out.
More controversially, support for ASP.NET is being dropped. Dreamweaver 8 came in for a lot of criticism from ASP.NET developers because it offered no support for ASP.NET 2.0. The vocal critics conveniently ignored the fact that Dreamweaver 8 was released several months before ASP.NET 2.0, so it was impossible for Macromedia (as it then was) to support a Microsoft technology that was still in the beta process. The disappointment was more understandable when Dreamweaver CS3 came out more than a year and a half later, and still had no support for ASP.NET 2.0. However, CS3 offered no new features for any server-side language, so users of PHP and classic ASP were just as disappointed that there were no new toys to play with in their favourite language.
Instead of leaving support for ASP.NET stuck in the past with ASP.NET 1.1, Adobe has taken the bold decision to remove ASP.NET completely from Dreamweaver. It will certainly annoy a lot of ASP.NET fans, but the message seems to be that Adobe would prefer to offer no support at all for a particular technology, rather than second-rate support. At the same time, the next version of Dreamweaver will no longer support JSP. This is likely to affect fewer users, but it sends a similar message—no support, rather than a half-hearted effort.
So does this mean that we’re going to see lots of PHP, ColdFusion and classic ASP goodies in Dreamweaver CS4? Adobe is keeping tight lipped about the new features it plans to put into the next version. Although I would love to see enhanced PHP server behaviors, the existence of Adobe Dreamweaver Developer Toolbox (an updated version of the old InterAKT Kollection) suggests an alternative scenario—basic server-side functionality in Dreamweaver, enhanced features in a separate product. However, I don’t see ADDT really taking off until Adobe changes the way it dumps more than 150 files in 30-odd folders into your site root, even if you need only one or two of those files to accomplish what you want. ADDT’s problem is that it’s a complete framework. It’s very good at doing things in its own particular way, but adapting the scripts to your own needs requires advanced knowledge of the inner workings of the framework. A lighter, more flexible approach is needed.
Two pretty sure-fire bets as to what will be in Dreamweaver CS4 are changes to the user interface and an updated version of Spry, Adobe’s implementation of Ajax. A lot of people criticized Dreamweaver CS3 for not using the OWL interface that Flash and the original Adobe programs, such as Photoshop, now use. (OWL, by the way, stands for Operating system Widget Library). There’s no doubt that OWL has a cleaner, less cluttered look, but I’ve been using it intensively with InDesign over the past week or so, and find a lot of little annoyances. For instance, if you collapse the panels to icons, only one panel can be open at a time. Also, the close buttons at the top right of each panel tab are too easy to hit by mistake. Worst of all, using the panels as fly-outs gets in the way of the main document window. Of course, you can use the panels in a fixed column, but the I find the labels often difficult to read. OWL is definitely an improvement over the old Adobe palettes, but I hope that further improvements will be made before it’s applied to Dreamweaver.
My views on Spry are still mixed. The version that shipped with Dreamweaver CS3 definitely had the feel of a beta—OK as far as it went, but still very much a work in progress.
Now that we know what won’t be in Dreamweaver CS4, it would be nice to know what new goodies we can look forward to. My own shopping list includes improved support for PHP and other server-side languages, and making it easier to create standards compliant (X)HTML and CSS. The Property inspector still supports a lot of deprecated or rarely used attributes. Providing consistent support for ID and title attributes would be a great start. Even better would be a Property inspector that hides all deprecated features if you choose a Strict DTD.
22 comments September 7th, 2007
It’s been a long time since I’ve posted anything in this blog. I’m definitely not one of the world’s most prolific bloggers—not by any stretch of the imagination.
One reason I’ve been so quiet is because of the pressure of writing The Essential Guide to Dreamweaver CS3 with CSS, Ajax, and PHP. It’s the longest book I’ve written (730 pages, not including Introduction and Index), and I needed to get it out as soon as possible after the release of Dreamweaver CS3. The book was finally shipped to the printers at the end of June, so it should be available at online booksellers and in bookshops on or around 23 July. I finished the book in record time—seven months from starting the first chapter to finally packing it off to the printers. In spite of the rapid turnaround, it’s been fully tested in the final version of Dreamweaver CS3. I’m also delighted that Tom Muck, the highly respected developer of Dreamweaver extensions and author of several books, agreed to be my technical editor. Between us, I believe we have created a great book. Please go out and buy it by the cartload. 
Another reason for not blogging much is the fact that, when testing Dreamweaver CS3, I have been under a Non-Disclosure Agreement. It’s hard to blog when the things you really want to write about have to be kept under wraps until the software is released.
9 comments July 7th, 2007
… or maybe they were just too polite to say.
I’m currently working on the draft of a new book about PHP, and decided to create a form to demonstrate the effect of the various arithmetic operators. I used the same set of examples that I’ve stuck with ever since Foundation Dreamweaver MX 2004. The example for modulo division is $x % $z, where $x is 20 and $z is 4.5. Since modulo gives you the remainder of a division, the result is obviously 2.
Well, at least that’s what I thought. It’s mathematically correct, so nobody ever questioned it. Imagine my surprise, then, when I fed this example into my form and the result came back as 0. Had I stumbled across a PHP bug?
I hunted around on the official PHP site, and couldn’t find anything. So I did some more tests. When I played with integers, modulo worked exactly as I expected. It’s just with decimal fractions that it behaved oddly.
Finally, I consulted Programming PHP by Kevin Tatroe and Rasmus Lerdorf, which reveals that, in PHP, the modulo operator converts both numbers to integers before performing the calculation. As a result, 4.5 was being rounded up to 5. Hence my mistake.
It’s nice to discover an error in one of your own books before others point it out, but it’s a bit embarrassing to have made the same mistake in four books. 
Strange that it’s not mentioned in the PHP manual, either.
6 comments March 8th, 2007
Let’s me nail my colours to the mast straight away: I use XHTML and have done so for several years. XHTML 1.0 has been a W3C recommendation for seven years (since January 2000). I’m aware of the well-argued objections by Ian Hixie, among others, against sending XHTML as text/html. Opponents of switching to XHTML 1.0 also point out quite rightly that XHTML 2.0 won’t be backwards compatible with previous versions.
So the arguments that break out in online forums from time to time about whether to use XHTML always tend to go over the same ground again and again: XHTML 1.0 isn’t really XHTML because it’s normally delivered using the wrong MIME type (text/html instead of application/xhtml+xml), and anyway everything’s going to change several years down the line when XHTML becomes the standard. My viewpoint has always been this:
Of course, you could use the same arguments about valid HTML 4.01. What matters most of all is that your code follows the rules and doesn’t rely on the forgiving nature of current browsers to cover up your mistakes.
This subject came up again a few days ago in the Dreamweaver forum. The discussion didn’t produce any real enlightenment, but it set me thinking. One of the arguments used in the past against adopting XHTML 1.0 is that “it doesn’t futureproof your site” because you’ll have to do everything again when XHTML 2.0 comes along. Then it struck me: that argument is completely wrong.
XHTML 1.0 is HTML 4.01 reformulated as XML. Since XML is designed to be machine-readable, it is futureproof. Pages designed with XHTML 1.0 may not be displayed by future browsers in the same way as XHTML 2.0, but the DOCTYPE will tell the XML parser how to read it. The same isn’t be true of HTML pages, even if they validate according to the 4.01 recommendation, because an XML parser will choke on empty elements, such as img tags.
6 comments January 2nd, 2007
As a result of lobbying here and in a private forum, the Dreamweaver 8.0.2 PHP hotfix is now freely available for download from this technote on the Adobe website. Thanks to Scott Fegette of Adobe and everyone else for their efforts behind the scenes to bring this about. Please note that the hotfix is needed only if you are using Dreamweaver to develop with PHP. It is required to complete chapters 9 through 12 of my book Foundation PHP for Dreamweaver 8. It fixes the following problems in PHP pages in Dreamweaver 8.0.2:
Add comment December 18th, 2006
| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| « Aug | ||||||
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 | |||||