Today is a good day to code

Safari and Standards Complicance

Posted: December 31st, 1969 | Author: | Filed under: JavaScript, Programming, Uncategorized | Tags: , , | No Comments »

Safari and Standards Compliance

Picture of Irv Owens Web DeveloperApple with Safari 2.0 has taken a major step toward standards compliance and largely are taking a leadership role in this area with its outstanding support for the Java runtime. I have heard some griping about Apple using KHTML, the default rendering technology behind the Konqueror browser for KDE, for a base, then running away with the open source once they have figured it out and not giving it back to the OSS community.

While I am extremely happy that Apple has made their browser Acid2 compliant, and they may have one of the fastest CSS rendering engines around built into the AppleWebCore. It is pretty upsetting that they would not share these advances with the developers working on KHTML so that it could also pass the Acid2 test. I can understand that some things you want to keep close to your vest for security reasons, but I can hardly believe that changes you have made to the way pages render in a browser could compromise your system integrity. This appears to be a situation in which Apple wants to be the most standards compliant platform on the market. This would be fantastic from a business standpoint since many in the scientific and mathematics communities would probably prefer to use technology that adhered to standards so as to better communicate information between offices, regions, and countries. I can understand that Apple wants to distinguish its platform from others, and I love the fact they are using standards compliance to do this, however I feel that it is to break the spirit of open source / corporate collaboration not to give something back to the KHTML community.

Speaking of Safari, I noticed a bug recently while writing some javascript for it. I have a javascript that sets the tabindex for a number of input fields, and it works properly, however in Safari it persists in scrolling the real browser scrollbar instead of the div, overflow:auto, element's scrollbar. I had noticed this way back in Safari 1.2 where if you put a flash item within a scrollable div, it would take the flash element and while scrolling lay it on top of all your other content, even if it was above or below the div. All other browsers, even IE 6, handle this properly, scrolling the div with the tabbing. This is a pretty big bug if they want to promote standards compliant web development and accessability. I'd like to see this fixed in Mac OS X 10.4.1, but after browsing the message boards elsewhere, I'd say they already have their hands full, so I am not supremely hopeful.

Microsoft is promising that its IE7 browser will be standards compliant, but just how standards compliant is really the question. I think that Microsoft has learned the error of its proprietary ways. Sure it will continue to bundle its software with everything anyone buys from them, but I don't think they will continue to cripple other products to make theirs look better. They seem to have given up on their own version of DHTML and are happy with XHTML. I noticed that their primary page even validates now. I think that it makes sense for Microsoft to go the standards route also, and with no shortage of developer feedback, they have almost no excuse not to.

Internet Explorer 7 Won’t Make the Grade on Acid

Posted: December 31st, 1969 | Author: | Filed under: JavaScript, Programming, Uncategorized | Tags: , , | No Comments »

Internet Explorer 7 Won't Make the Grade on Acid

Picture of Irv Owens Web DeveloperAs the market leader and pace-setter as far as which technologies make the cut for the web Microsoft has a responsiblity to create the most standards compliant browser possible, even at the risk of breaking legacy sites built specifically for IE. Microsoft has always wanted developers to use it's unusual flavor of IE. Whether it is by building extra padding into block level elements regardless of how the css padding attribute is used, or allowing oddities like allowing the use of the color attribute on TR table elements, developers have always had to consider the quirks of IE when building anything for deployment over the web.

I'm sure that IE 7 will be much improved over IE 6 as far as standards compliance is concerned, and some of those oddities I truly enjoy, like being able to give a TR an ID attribute and specifying a header style for my tables in a stylesheet, but at the same time, if we don't have web standards we'll devolve into fragmented development languages like it was 1995 all over again. IE 6 actually had excellent standards compliance when it came out, but times have changed and there are some advanced features like page-break-after that I'd love to use more widely. Part of the reason I love to build intranet applications for Mac only shops is that I know they will be using Safari 2.0 which is an excellent browser based on the open source Konqueror browser bundled with many Linux distros. It supports most if not all CSS 2 tags, and should pass the Acid2 test with ease. Also, by developing to XHTML 1.0 Strict I know that my site will degrade gracefully on everything from mobile devices to old 3.0 browsers. Using ECMAScript also keeps most backward compatability and allows developers to create reliable JavaScripts that will work across all compliant browsers in the same fashion.

I agree with Hakon Lie that Microsoft should really take more time and make sure they nail this one, not just for right now, but for the future since we all know they won't release another web browser perhaps forever since they are convinced that Avalon will change the face of web applications and render the web browser superfluous. We've heard that one before, remember Active X? I hope that everyone calls on Microsoft to work to get IE 7 to pass the Acid2 test, not just so that it will support some bizarre standard that is going to make all our lives harder, but so that developers can be sure that applications they develop today will still look and work the same five years from now. C'mon Microsoft please?

Next Explorer to fail Acid Test – CNET

Configuring ColdFusion MX 7 and Apache

Posted: December 31st, 1969 | Author: | Filed under: JavaScript, Programming, Uncategorized | Tags: , , | No Comments »

Configuring ColdFusion MX 7 and Apache

Picture of Irv Owens Web DeveloperAnother issue I kept coming across during my configuration of the XServe G5's Apache and JRun4 was that the virtual hosts didn't seem to be resolving. The same site appeared to collect all the hits. After several hours last night troubleshooting, I finally found the culprit.

When the JRun / Apache bridge is configured, a small module is built and plugged into Apache that allows it to process ColdFusion templates from within its default web root. This functionality is great, it allows a user to serve up .jsp, .php, and .cfm files from the same folder. A single modification is needed to JRun to allow web users to get to your files without having to add /cfusion to the end of their URL request. In JRun there is a setting under the “Application Server” > “Summary,” you will see a section titled Web Applications. Under this header there will be two apps if you have JRun and ColdFusion set up correctly. They will read “CFMX RDS Application” which we are not going to do anything to, and “Macromedia Coldfusion MX,” which we are going to change. If you click on the name of the application “Macromedia Coldfusion MX,” you will see a simple screen that will show you the current context path for the application, which should be “/cfusion” or something similar. If you change it to “/” then your templates will run from the root domain.

With this process, however there are a couple of caveats. You may have to copy all of the coldfusion JavaScript files to a cfusion subdirectory in your applications folder, if you are using ColdFusion forms validation. Also, the images for the administrator will nont appear when you work with the administrator. Accessing the administrator is not quite as straightforward as you might expect, also. A minor change is needed, it obviously no longer needs the “/cfusion/CFIDE/Administrator/index.cfm,” instead it now will use “/cfide/Administrator/index.cfm.” Make sure to make the “cfide” lowercase or it will not work.

Once you have this working, if you already have applications loaded into the “JRun4/servers/cfusion” directory, and they happen to have the same folder name as the ones in your Apache web root folder, then when you call your templates, the server will not know which ones to pick which will have the effect of causing long nights of hair pulling to figure out why your file changes have no effect on the operation of the server. The resolution is simple, do not use the servers directory of JRun to execute your web applications, instead use the Apache web root. You will have to delete any common files between the appliation in your folder within the JRun servers folder, and the Apache web root. Basically just delete your web application from the JRun application folder, and have it only located in Apache's web root, if you haven't already gotten that.

My issue was that both files had the same index.cfm file, and what was happening was that the virtual root was resolving properly, but a cflocation tag that I had in the index.cfm contained within my JRun servers directory was being chosen over the same file in my Apache web root. Once I deleted the version of the application in the JRun folder, the issue disappeared, the server was behaving correctly.

The moral of the story, don't leave superfluous files around your server, they will always come back to haunt you in the end.

What is this Y!Q stuff?

Posted: December 31st, 1969 | Author: | Filed under: JavaScript, Programming, Uncategorized | Tags: , , | No Comments »

What is this Y!Q stuff?

Picture of Irv Owens Web DeveloperYou may have noticed all of the Y!Q links everywhere on my site. It is a new beta product from Yahoo! that allows people to perform web searches constrained by selected content from the page they are searching from. The content that goes to Yahoo! is selected by the publisher and targeted to return even more relevant results than would be possible going directly to the search engine.

When a user visits a search engine, the system has no background about the person to constrain their results so it makes it difficult to perform a search, for example if I knew someone were from Washington State, and they typed in the word apple, then I could assume they might be looking for apple wholesalers, or apple growers, or apple trees. If someone from California searched for the word apple, I might return the company. This is possible if you know something about the person who is searching, which is why personalized search has been receiving more focus of late.

I prefer the context based approach, because then I don't have to provide any personal information for the search engine to give me what I want. It would know just by the content of the web page that I am searching from.

I'll be honing the coldfusion parsing scripts to give the best possible content to Yahoo! I'll be removing words that are less than four characters in length from the article, to get rid of parts of words and words that carry little meaning like 'the.' I hope to have the best, most relevant results, because Yahoo! is offering $5,000 in their contest. Of course there had to be some motive for me to use this beta program!

I suppose that in its final iteration, Yahoo! will create some type of advertising revenue sharing model similar to Google's adwords. They seem to be hoping that it will generate more clicks because of its usefulness to the user. It is still kind of buggy, for example in all browsers other than Safari 2.0 a semi-transparent overlay pops up when the Y!Q link is pressed, on Safari, it takes you to Yahoo's relevant results page. Hopefully they will fix this soon, I'm pretty sure it has something to do with the changes Apple made to Safari's javascript processing engine. Also, since I am trying to automate this, sometimes a character gets into the string, and causes the Y!Q to return something not valid. I hope this will help with your searching.

JoostBook – Joost to Facebook Interface Widget

Posted: December 31st, 1969 | Author: | Filed under: java, JavaScript, Programming, Uncategorized | Tags: , , , | No Comments »

JoostBook – Joost to Facebook Interface Widget

Picture of IrvinSince I'm in love with Joost, I have been thinking about good applications that I could write for the platform. Before I get into talking about the widget / plugin, let me just say that the experience I have had with communicating with the Joost engineers, through their joost-dev google group, as well as them allowing early access to their SDK, has been outstanding. I have rarely come across a more open and generous group. Typically, the SDK guardians are very selfish about discussing future features, and are usually quite arrogant about the possibility of a developer finding an undiscovered bug. None of this has been the case with the Joost SDK staff.

If you don't want to read the details about how I built it, and you just want to use it, you can get it here: JoostBook: Joost / Facebook Interface. You will need Joost, and a facebook account to get started.

Now, about the widget. Firstly, the installation is a little wierd because of the level of control facebook insists on. In order to use the SDK, you have to authenticate, if an unauthenticated request is made, the response is with the facebook login page. This makes for some unique error catching conditions.

Secondly, we web developers often take for granted that the DOM will have a listener attached to it, and will automatically refresh if anything in the DOM changes. Well, I know that the Joost engineers are working on it, but it doesn't refresh, and therefore, while you can create new XHTML elements, as well as modify the ones that are there with JavaScript. You are best off currently just hardcoding all of your objects up-front, and changing their contents. Also, injecting XHTML using innerHTML doesn't really work so well currently either. I'd suspect that much of this is because there is a bridge between the 2D world of XULRunner / Mozilla, and the 3D world of the Joost interface. I'm sure there is a lot of complexity between the two.

So basically, once you have downloaded Joost, and installed the plugin, the first thing I had to do was check for if you are logged in, if you aren't logged in, it has to show you the facebook login page in an iframe so that the XULRunner browser can be cookied. After that, the widget should work like one would expect. You may have to log in alot, and if you aren't logged in, obviously the application can't update the JoostBook facebook application.

Writing the Joost plugin was the easy part, getting the facebook stuff to work was the hard part. Most of it was because the error handling is terrible. Since facebook doesn't allow you to see the 500 errors that your server is throwing, and it doesn't log it, you have to find other ways to check to see if your server is behaving properly. I spent a lot of time in my logs checking for errors.

The install process is a little wierd too, for example, in Firefox on Windows XP, when I clicked on the Joda file linked in the page, it tried to open it as if it were some kind of markup file, obviously the joda looked like garbage, I had to right click and save. Perhaps if I had used a joost:// link it would have worked OK, but I think more research is in order. I didn't really try it in IE because most of the readers of this blog use Firefox, but it should work the same way.

Then having to install the application in facebook can be a little difficult as well. Well, the installation isn't difficult, its the concept that you have to install two applications that work together that is hard. At least there is no particular order in which you need to install them, worst case whenever you run the JoostBook plugin in Joost, it'll show you the facebook login page all the time.

At any rate, it was a fun experience, and I still think the guys at Joost are on to something. I'm slightly less psyched about the facebook platform, but I'm still excited about it.

Big Iron (Mainframes) and the World of Tomorrow

Posted: December 31st, 1969 | Author: | Filed under: JavaScript, Programming, Uncategorized | Tags: , , | No Comments »

Big Iron (Mainframes) and the World of Tomorrow

Picture of Irv Owens Web DeveloperThere was an article in CNET yesterday espousing the need for developers to pick up mainframe development, and schools reinstating their mainframe classes. While I don't think anyone should waste their time learning about a mostly dead technology, it makes sense to learn from the applications developed on mainframes and take the lessons with a grain of salt.

Right now I am working on converting a legacy mainframe application that was implemented in the 1970's into a web application. The real issues are stemming from the current business process with that mainframe. The database, probably some RDBMS variant, is normalized in such a way that it makes enough sense to keep that structure rather than try to re-invent the wheel. What has been suprising is that it also makes sense to maintain most of the data presentation layer.

The people who use the current system get a ton of data from a very small amount of screen real-estate. The mainframe systems were usually text based, and limited in the number of characters that could be stored in a field, and therefore displayed. Much of the business process that resulted from these limitations has evolved around using codes and cheat sheets to figure out what the codes mean. This also has the effect of shielding somewhat sensitive information from outsiders and customers. The use of codes as a shorthand for more detailed information also has the effect of being able to transfer a large amount of knowledge in a very short time for experienced users. Similar to the way we use compression to zip a text-file into a much smaller file for translation later. When a user inputs the code, they are compressing their idea into a few characters that the user on the other end can understand.

I have been more fortunate than most, because I have access to one of the original architects of the system, and I believe that having an understanding of the business environment and the system architecture is more important than knowing the actual code. Most people looking to hire individuals who understand the mainframe are really looking for people to dis-assemble their applications and rebuild them as web applications.

I do intend to maintain the look of the existing mainframe screens, but intend to replace the current cheat-sheets with simple hover javascript events to display descriptions of what the codes mean. I like this approach of blending the old with the new since it will create a sustainable bridge between the legacy users and incoming users who may not have had the same experience.

The article in CNET further implies that mainframes still sport some advantages over server based applications. That may be true to a degree for deployed desktop applications, but maiframes have no advantage when it comes to web applications. Still, people who know COBOL, FORTRAN, and other low level languages can command a premium for their technical knowledge in the few shops who feel that maintaining these mainframe applications and hardware are better for some reason than replacing them, but it is only a matter of time until these shops agree that paying an ever increasing amount for maintenance and upgrades is more expensive than bringing someone onboard to convert the application to the web. Therefore I see no future in the mainframe, however some great applications were developed for them, and the applications that are still running on them were probably more robust than average.

Much of the methodology I tend to follow when constructing a database or organizing code were implemented for the first time on big iron, so I actually feel priviliged to be able to work with it. Its almost like looking into a time machine where you can see and feel the environment of the past which, even though it may seem the same, is vastly different than the business climate today.

Learn COBOL today!

What is a mainframe anyway?

Macromedia / Adobe Flash and AJAX: Companions or Adversaries

Posted: December 31st, 1969 | Author: | Filed under: JavaScript, Programming, Uncategorized | Tags: , , | No Comments »

Macromedia / Adobe Flash and AJAX: Companions or Adversaries

Picture of Irv Owens Web DeveloperOne of the hottest new things in web development right now is pretty old. JavaScript is taking the world by storm through the XMLHTTPRequest. My question is, isn't this exactly what Flash MX was designed to do?

I have only been working with Flash for about three-and-a-half years, and one of the first things that drew me to it was the ability to get and post to other pages without a page refresh. Flash was designed to do this from the beginning. With the ColdFusion flash gateway, developers can even directly access CFCs and other template pages. The question then is do we really need AJAX?

I think so. One of the benefits to using AJAX is that it is possible to create standards compliant web pages that are more dependent on the resources of the client and less on the server. Back in the nineties, it was much better to rely on the servers because they often had more computing power, but now desktops are very powerful and most can handle the rigors of sorting and validating data. These are probably some of the more banal uses of AJAX, but these are things that should be handled by the client and not the server.

There will be some overlap between AJAX and Flash. Many in the AJAX camp will claim that AJAX is much lighter than Flash as far as bandwidth is concerned, and I can see that poorly designed Flash will take more bandwidth than well designed Flash. It is possible to draw components with actionscript. This puts the drawing entirely up to the client, with the Flash movie being mostly just compressed script. If AJAX needs to use graphics, it has to send them via CSS during the initial download, and afterwards these images will be available as long as they are in the browser's cache. It is even possible, as it is in Flash, to have the initial page appear while still downloading components.

I think that for some projects AJAX will be the technology of choice, but for others Flash MX will be optimal. Personally, I believe that for most of the jobs you could do with AJAX, Flash will be the faster solution because of the well designed nature of the IDE. Flash is now a platform and the Flash Development Environment is the tool. Macromedia is going to embrace Eclipse to try to get Java developers to see the benefits of creating web applications with Flash. I think that in the long run, Flash is a good bet, and that AJAX is sort of a fad that will become less and less a good choice as bandwidth becomes more available. I like a lot of what is happening with AJAX, and hopefully the developers of Flash will keep working toward accessibility. But in the end, well designed flash applications are hard to beat. They don't need screen refreshes, the Macromedia components are well designed and often will take XML as their data source. The applications allow more interface flexibility than traditional CSS, although this is changing, and overall lead to a better user experience.

So why do I bash Flash constantly? My negativity where Flash is concerned comes from having to endure many, many very poor Flash websites and applications that use Flash just because it moves. The developers often spend little or no time in working with the actionscript, and they don't plan for low bandwith users. Many Flash developers believe that the dial-up and ISDN / Mobile users don't matter and that is simply bankrupt thinking. Developers should plan and develop for the least common denominator. A light design can still be a good design, and is often, in my opinion, the best design. AJAX lends itself to better developer practices by its complexity, but I don't believe that complexity is ever a good solution to a problem. Perhaps with the introduction of AJAX tools, and an IDE this complexity could be improved upon, and we are already seeing the beginning of the uses of AJAX in web applications and they are quite impressive, but most of the impressiveness comes from the fact that they are doing it without Flash, not from the application itself.

The fact is that over 90% of the web is Flash plugin enabled, and it is a relatively small and fast download. If you want to design really solid applications, take everything you have learned about minimal design and apply that to flash development. Perhaps then, Flash can turn its negative image around and become a real tool for business solutions.

About AJAX
Flash Remoting LiveDocs

Why Flash is Still Oh, So Wrong for So Many

Posted: December 31st, 1969 | Author: | Filed under: JavaScript, Programming, Uncategorized | Tags: , , | No Comments »

Why Flash is Still Oh, So Wrong for So Many

Picture of Irv Owens Web DeveloperI have recently come under some minor pressure from various factions about why, while knowing Flash fairly well, I am always reluctant to design and build a flash site featuring the technology. My history with Flash is pretty much the same as most other developers. My first versions of this very site three or four years ago were made entirely in Flash, as were many of my customers sites. Flash seemed like the way to go. It rendered the same in every browser, fonts weren't an issue, and it allowed an incredible amount of freedom to create.

So why then were my sites so problematic. The first issue was one of bandwidth. I had music and lots of motion on these sites. They were extremely interactive and eye catching. The problems came up when users had to come to my site using dial-up. When they hit the site and saw the loading bar, the first thing they did was to click back and go on to another site. My webtrends illuminated this for me. My next step was to go more minimal, which is my favorite thing to do, but then I wondered why I was using Flash at all, because now the motion was mostly gone, and so was the majority of the interactivity. I was using flash simply for the z-index, and I was finding that I could do this with CSS. So, not to be deterred, I did another redesign that kept the motion and interactivity, but minimized the huge bitmap graphics that were giving me the long download times. Instead, I used vector graphics. These were much smaller, but now I had a new problem. If my clients didn't have at least a Pentium 4 running at greater than 2 GHz, my site ran slowly, so slowly that it was almost unusable.

The next issue was that in all the time I had my site, I could never find it using search engines. I discovered that search engines couldn't index my site because they couldn't see through the Flash. To the spider, my site looked like a huge gif in a HTML file with some meta-tags. In other words, it looked like nothing. I tried alt tags, no script tags, etc… but nothing helped. Finally, I decided to design an alternate site for dial-up users using good ol' XHTML and CSS. I found that as soon as I uploaded the file, the search engines had me, and no one ever visited my Flash site anymore.

Suffice it to say that I took my Flash site down. Later, I would redisign my site again so that it would adhere to web standards and could render even faster for all users. That site is this one, and it is the first that I am happy with. I am enjoying some minor success with getting listed on search engines and blog aggregators, and life is good.

I don't hate Flash any more than I hate Allen wrenches or crowbars. It is a tool, and typically you try to use the right tool for the job. It seems to me that many web developers, however are trying to use a sledgehammer to staple two pages together. It just doesn't work. In some cases Flash is OK. In corporate settings, Flash is an excellent tool for presentations, product demonstrations, promotional materials delivered through the company intranet, or from the presenter's local hard drive, as long as it doesn't have to be delivered over the web.

There are a few cases where it is perfectly reasonable for designer / developers to build flash-only web sites for people. Art sites, such as photography showcases can benefit from Flash and its fantastic bitmap compression. Flash photography sites can often download faster than their HTML / CSS counterparts due to smaller image sizes. Some product demonstrations can benefit from Flash and its interactivity. Many cellular phone providers have used Flash to great effect in this regard. Simple branding banners contained within standard HTML / CSS pages with limited motion and interactivity can be excellent, as long as the text of the page is available for the user to read while the Flash is loading.

Still, designers and developers need to ask themselves, what exactly am I trying to do, and who is my target customer? I have had a very hard time making a solid business case for Flash on most of my ecommerce and business sites. Flash, like ColdFusion and Chess, takes only a minute to learn, and can take a lifetime to master. There is a lot to Flash, and a good designer knows how and when to use it to make a site look more professional, or to enhance content that may otherwise appear to be bland. However, beginners seem to tend to develop only in Flash because it addresses many of the apparent problems with XHTML / CSS. Those of browser incompatability, having to learn JavaScript, etc. Someone with limited knowledge of ActionScript and no knowledge of HTML is able to open Flash MX 2004 and create a website. Many designers use Flash exclusively, for this reason.

It seems that XHTML / CSS / JavaScript is having a renaissance. With the proliferation of blog sites, and better browser support of web standards many Flash sites are starting to look tired, and compared with the relative quick response of the HTML sites, many users are deciding to click away from the loading screens in favor of a site with similar content, or products, that is designed in standards compliant XHTML. Not because they love web standards, but because to the user the XHTML site works better and they don't have to wait. I have actually heard designers say that they don't care if dial-up users can't access the site, it has to be beautiful. This thinking is bankrupt, probably 80% of the country is still using dial-up. BroadBand is still frequently ridiculously expensive, and until this changes Flash will be limited to design and car sites mostly, while the bulk of the web is built using XHTML.

I'd actually like to see that change. I'd like to see 3 Mbps synchronous connections standard in every home across the country, and Flash sites loading instantly, but the reality is that it won't happen within the next 5 to 10 years. At least not until garbage cable company decides to charge reasonable rates, and build better fiber backbones, and adequate DNS resources.

In the meantime, I'm quite happy with CSS / XHTML. It does everything I used to do with Flash, but it does it faster and is more accessible. Hopefully more designers will build standards compliant sites, and will realize they can be every bit as beautiful as Flash sites. Check out to see other great CSS designs.

New Internet Explorer 7 to Allow More Customization

Posted: December 31st, 1969 | Author: | Filed under: Google, JavaScript, Microsoft, Programming, Uncategorized | Tags: , , , , | No Comments »

New Internet Explorer 7 to Allow More Customization

Picture of Irv Owens Web DeveloperI love the ability I have to add more functionality to Firefox. Right now I have the web developer tools so that I can check out a page's stylesheets, javascript, block level elements, etc… I have the IP tool installed so that I can see the IP address of the site that I am currently visiting. I have the Gmail notifier and the PageRank tool all incorporated in my browser, most of which modifies the status bar at the bottom of the browser and is completely innocuous. Internet Explorer has always supported plug-ins, but they were limited in their ability to change the user's browsing experience, relegating them to toolbars and the like. That is about to change.

Similar to the new Google dashboard Internet Explorer will allow small web applications to be installed in the browser, it will allow a user to modify the webpages they are viewing, create a new download manager using the .net languages, really the implications seem to be pretty huge. There is just one problem. Security.

One of my biggest fears with a heavily extensible Internet Explorer is that people will be able to use it to compromise the security of the operating system. We have heard time and time again that in Longhorn, ahem, Vista, users will be able to run Internet Explorer 7 in a sandbox of sorts, or a least privileged user account, preventing would be hackers from compromising the system. That is great for Vista, but what about on Windows XP Service Pack 2? Don't get me wrong, I think Microsoft has done as much as can be expected of anyone when patching a completely insecure OS, and they did it in record time too. Still, there have been plenty of bulletins regarding more compromises and exploits in Windows XP SP2, some regarding Internet Explorer. If you give individuals the ability to distribute code that a user can install, it is possible, by definition to compromise that user's system. I'm sure that Microsoft would be quick to point out that then it isn't their fault that someone installed software that allowed hackers to have their way with all their files, but at the same time it is very easy to misrepresent a piece of software to a computer novice who is using Windows. Just look at how far Gator / Claria has gotten sneaking software onto systems. I think that while having the ability to customize one's web browser is cool, Microsoft should consider passing on this potential nightmare. It is sort of reminiscent of Microsoft's touting of Active X and how it was going to obliterate the line between desktop software and internet applications and change the way we all use our computers. Well, it changed the way we all use our computers, we all need anti-virus / spyware / malware filters that sniff out those Active X controls and disable them. Most of us, those in the know, if we have to use windows, turn the Active X controls off altogether.

I think that Microsoft should really not include this feature, and I mean even for toolbars unless they are reviewed by Microsoft and signed by Microsoft. That is the only way to be sure users aren't getting malware. If the plug-in isn't signed by Microsoft then the OS should refuse to install it. It should be that simple. Of course it makes developing for IE that much more difficult, but Microsoft could release a developer's version of IE that was open source so that the plug-in verification could be disabled to allow all plug-ins to be installed. Everyone in the software business knows that features move boxes, but Microsoft should keep their eyes on the prize of security. They really need to get their reputation back, and integrating more sketchy features in not the best way to do this.

IE Extensibility – From the IE blog

Flash Forms in ColdFusion MX 7

Posted: December 31st, 1969 | Author: | Filed under: ColdFusion, JavaScript, Programming, Uncategorized | Tags: , , , | No Comments »

Flash Forms in ColdFusion MX 7

Picture of Irv Owens Web DeveloperOne of the coolest things in the not-so-new-anymore ColdFusion MX 7 release is the ability to use Flex and ColdFusion tags to generate Flash components without having to design them. One of the perennial headaches for a web developer has been the difficulty in creating self-validating forms, and grid components that could take the stress of sorting off of the web or database servers.

I am not really too into screenshots so I will just show you a sample of the new flash forms. I am not sure if they validate or not, but they are definately cool. The built in forms validation is excellent also, it is handled completely on the client. If you press the submit button without entering any text in the you must enter some text field, it will show you the error. The binding is sweet too, you can bind one item to another in a form. If you notice, when entering text in the top box, you will see the bottom box mirroring it.
Flash Form Example

That is sweet for many different reasons, here is the code behind it:

<cfform name="code" action="" method="post" format="flash" height="600" width="639" preloader="true" timeout="100" preservedata="yes">

<cfformgroup type="tabnavigator">

<cfformgroup type="page" label="Text Entry">

<cfformitem type="text">Enter Some Text

<cfinput name="aninput" type="text" required="yes" message="You must enter some text" />

<cfformitem type="text">Bound to the Above Text Box

<cfinput name="bound_input" type="text" bind="{aninput.text}" />

<cfformitem type="text">A Text Area

<cftextarea name="moreText" value="Some More Text" />


<cfformgroup type="page" label="Grid Component">

<cfgrid name="myGrid" width="624" height="350" query="theQuery" format="flash" align="absmiddle">

<cfgridcolumn name="title" header="Title" />

<cfgridcolumn name="dateEntered" header="Title" />




<cfinput name="Submit" value="Submit" type="submit" />


Another really cool item is the cfgrid component. It is a fully featured flash grid that can show any number of objects. I am toying with the idea of implenting it on my search page, using javascript to show and hide the results, but that seems like overkill. I would show one to you in action, but you’ll just have to settle for the code.

This will create a nice grid component that handles sorting for you. It will draw its data from the query myQuery. Each column will pull from the field in the database according to its name. For example the date column will get its data from The others will get their data similarly. I don’t know why I didn’t use flash forms before. They are certainly cool. You can bind to the data in the columns so you could have a field that would allow you to edit the currently selected field in the database. This is extremely handy in creating sensible and usable forms. I hope this helps, some java application servers don’t support flash forms, in fact I am not certain that this one will. However I’ll try, if it doesn’t work, at least the code may be helpful.