Flex, Java/JavaFX, Silverlight, AJAX & RIA Frameworks

RIA Developer's Journal

Subscribe to RIA Developer's Journal: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get RIA Developer's Journal: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


RIA & Ajax Authors: Javier Paniza, Pat Romanski, RealWire News Distribution

Related Topics: RIA Developer's Journal, ColdFusion on Ulitzer

RIA & Ajax: Article

The MX Blogosphere

Around the MX world in 80 blogs

If one of the true signs of a vibrant developer community is an active blogosphere surrounding a technology, then the MX suite of technologies certainly passes that test with flying colors. In case you're not yet active yourself, MXDJ brings you a comprehensive selection from some of the best known (and many of the not so well-known too). Don't forget that you can blog yourself now, too, at the MXDJ site - you can get started in just 3 minutes at http://blog-n-play.com.

Blog Topic: Dreamweaver

Dreamweaver Extension Virus?
By Tom Muck from "Blogging on MX"
(http://tom.mxdj.com/)

Many users have problems with rogue extensions, bad extensions, or extensions that have been uninstalled improperly. Dreamweaver's Extension Manager is not entirely reliable when installing/uninstalling extensions. This is because of the way that modern operating systems work with multiple users, and because Macromedia, like other software companies are forced to comply with a multi-user configuration.

When you run Dreamweaver, you can be logged onto the operating system as yourself, the computer Administrator, or another user. When you install an extension, the files are not installed to the main program directory, as they were in the past with Dreamweaver 4 and earlier. They are installed in the local user directory, or in the All Users directory.

Danilo posted about the Dreamweaver configuration folder locations in a previous entry at CMXtraneous (www.communitymx.com/blog/index.cfm?newsid=27).

One of the major problems that has plagued extension developers from the beginning is when a rogue extension developer overwrites a Dreamweaver system file, or any Dreamweaver Configuration folder file. For example, some extension developers try to add additional functionality to the Dreamweaver Recordset. Instead of creating their own version of the Recordset files (such as Recordset.htm and Recordset.js), they modify the existing Dreamweaver files.

That works great if this is the only extension the user will ever install. If the user wants to install an extension from another developer, however, this could severely break the way that Dreamweaver works, because expected functionality might not be there or might act differently. Additionally, if two rogue extension developers overwrite the same file, one of them is out of luck because the second extension overwrites the first extension.

Make no mistake, when a Dreamweaver configuration file is overwritten by an extension developer, it is the equivalent of a virus, a spyware or other intrusive worm. The installation is now corrupt. Additionally, some extension developers are including a directive in the .mxi file that creates the extension package, putting a systemfile="true" directive for each system file that they overwrite. This causes problems as well, because when you uninstall the rogue extension, the bad system file is left in your Dreamweaver installation. The effect of this is that your Dreamweaver installation is corrupted. Dreamweaver is using the corrupted file rather than the file that Macromedia created.

Another problem exists: when Macromedia comes out with new versions of Dreamweaver, these rogue extensions are still being distributed, and are being used by users. Let's say, for example, that a new version of Dreamweaver has to change the Recordset.js file in order to work with some new functionality. A user installs an extension that overwrites this file using a version from the last version of Dreamweaver. The program is now broken with no way to recover other than deleting the local All Users or the local user folder, or just making it easy on yourself and reinstalling Dreamweaver.

More problems: If a Dreamweaver user decides he wants to modify a file in the Configuration folder, if the file has been overwritten by an extension developer, the user's changes are not respected.

An additional note: when I say that the file is "overwritten," it's not entirely accurate. In a modern operating system, the files are not overwritten in the main Program Files directory (Application directory on the Mac). The files stored in the All Users supersede the files stored in the Program Files directory. In other words, if Dreamweaver requires a Recordset.js file to run, the file will remain untouched in the Program Files directory, but a new version of the file is stored by the Extension Manager in All Users. However, to the uninformed user, this is the equivalent of a corrupt installation. The typical user does not know that there is a special hidden directory that contains rogue extension files.

What to do about this? Well, the first and most important step is to convince these rogue extension developers that what they are doing is harming the community. In their overzealous approach to adding functionality to Dreamweaver, they are basically spoiling the program for other extension developers, and setting the average Dreamweaver user up for a corrupted installation full of JavaScript errors every time they want to open a file. Secondly, Macromedia should step up to the plate and disallow extensions to be downloadable from the Exchange if the extension modifies core Dreamweaver configuration files. Lastly, users should write to extension developers that do this and demand that they stop.

It is a political issue, unfortunately. The extension developers who do this (I'm not naming names) insist they are trying to make Dreamweaver better. Some of us extension developers who have been around a while have always made an effort to extend Dreamweaver without ruining it for the next guy, though. Sadly, if it keeps up, more extension developers will do it and before you know it every extension you install will overwrite some other guy's file, and no extensions will work. What a mess that will be. . .

I issue a challenge to all Dreamweaver extension developers to stop this practice. It's already late, but we can minimize the damage going into the future. Extension development has come a long way since the early days of Dreamweaver, but if we can't develop extensions in a responsible way, it is going to impact the way that Dreamweaver users view extensions.

What to do if you have a corrupt installation? The first thing you should try is uninstalling the extension. Of course, that doesn't work always because of reasons I've stated. If it doesn't work, find the local Configuration folders mentioned above (not the main Program Files directory) and rename them or delete them. This will completely remove all extensions so that your Dreamweaver installation will be fresh again. Alternatively, reinstalling Dreamweaver should do this as well.

Blog Topic: MX Blogging

"Googlejacking"
By Cameron Childress from "Cameron Childress' Blog"
(www.sumoc.com/blog/)

It all started with reading a thread on Slashdot about "Google Hikacking." For those just tuning in, here's a summary of what Googlejacking is (from http://clsc.net/research/google-302-page-hijack.htm):

"An explanation of the page hijack exploit using 302 server redirects. This exploit allows any webmaster to have his own "virtual pages" rank for terms that pages belonging to another webmaster used to rank for. Successfully employed, this technique will allow the offending webmaster ("the hijacker") to displace the pages of the "target" in the Search Engine Results Pages ("SERPS"), and hence (a) cause search engine traffic to the target website to vanish, and/or (b) further redirect traffic to any other page of choice."

Here's what happens:

  1. Googlebot goes to scammer's site
  2. Googlebot is given a 302 (redirect) to the victim's site
  3. Googlebot indexes the victim's site as belonging to the original URL
  4. Googlebot goes to the victim's site
  5. Googlebot realizes this URL is already indexed and "belongs" (according to the Google code) to the scammer.
  6. The victim's site gets lower rankings as the page is not even indexed, the scammer's site gets a higher ranking.
A more detailed listing of how it works can be found in this Slashdot comment: http://slashdot.org/comments.pl?sid=143465&cid=12024264 . If you have a Macromedia-centric blog picked up by an aggregator and want to test if your blog has been Googlejacked, type the following into Google:
allinurl:yourdomain.com

If some of the search results include pages containing the exact content and title as your blog, yet have a different domain, you've been Google Jacked. Admittedly, and per the descriptions in the above linked paged, this could be by accident some of the time, but the biggest offender in this case for me is edelina.com. Go ahead, type that domain into your browser (I'm not giving them any more link visibility by linking to them). It's a craptastic cornucopia of spammy junk, and they have a 302 redirect up an entire family of Macromedia-centric blogs. I've checked others, and we are virtually all there as far as I can tell.

Google Hijacking is worse than someone simply syndicating your blog content on their site because it's actually faking our Google to think that it is your site via 302 redirects, which mean "temporarily moved" as opposed to 301 which mean "permanently moved."

After a little more investigation, I found that the DNS host for edelina.com is Abadon Studios based out of Aliso Viejo CA. Searching for "Abadon Studios" in Google also reveals that they have a metric ton of other craptastic ethically questionable SEO domains for all sorts of things.

The worst part of it is that the slimeball behind all of this seems to be using Fusebox, which means he's "one of us."

If you are affected by this, instructions on what to do about it can be found posted by Google Guy on the Slashdot thread (http://slashdot.org/comments.pl?sid=143465&cid=12024599). It boils down to contacting Google's user support (www.google.com/contact/spamreport.html) and using the word "canonicalpage" in the complaint.

I would encourage anyone with an affected blog to make a complaint.

Blog Topic: Cold Fusion

Hide Your Errors
By Steve Bryant from "A Web Programmer's Exploration"
(http://steve.coldfusionjournal.com)

I have noticed that a great many ColdFusion sites show the default ColdFusion error when something goes wrong. This is a bad idea for many reasons.

In the "Research-Based Web Design & Usability Guidelines" put out by Usability.gov, "Detect Error Automatically" was given an importance of 5 out of 5. In his popular "Top 10 Web Security Tips" (www.sys-con.com/story/?storyid=46366&DE=1) article, Michael Smith listed "Have an error-handler" as his number one security tip.

In his article "Toward Better Error Handling" (www.sys-con.com/coldfusion/article.cfm?id=165), Charlie Arehart covers some techniques for error-handling in ColdFusion. As of the release of ColdFusion MX 7, a new method exists for handling errors in ColdFusion; the onError event of Application.cfc.

The onError event is only available if you are using Application.cfc. To get an introduction to Application.cfc, see my "Application Events:onRequest" (http://steve.coldfusionjournal.com/read/1059556.htm) blog entry or see the LiveDocs for Application.cfc (http://livedocs.macromedia.com/coldfusion/7/htmldocs/00000692.htm).

To add the onError method to your Application.cfc, simply add code like the following to Application.cfc (replacing the comments with whatever code you want to run when an error occurs).


<cffunction name="onError">
    <cfargument name="exception"
      required="true">
    <cfargument name="EventName"
      type="String" required="true">
    <!--- Error handling code here
      --->
</cffunction>

Of course, ColdFusion will raise an exception (and run the code in onError) when it runs in to a <cfabort>.

In order to prevent that from adversely effecting your code, he suggests adding the following lines to the top of your onError method:


<cfif arguments.exception.rootCause
  eq "coldfusion.runtime.
  AbortException">
    <cfreturn/>
</cfif>

So now our onError method looks like this:


<cffunction name="onError">
    <cfargument name="exception"
      required="true">
    <cfargument name="EventName"
      type="String" required="true">

    <cfif arguments.exception.
      rootCause eq "coldfusion.
      runtime.AbortException">
        <cfreturn/>
    </cfif>

    <!--- Error handling code
      here --->

</cffunction>

So, now you can just take this code and add your own error-handling code (for example, display a user-friendly message and send yourself an email), right? Well, almost.

While ColdFusion MX 7 is a lovely product, it has a few bugs that still need to be resolved. One bug occurs if you are using jsessions and a session expires. It results in a "Session is invalid" error being displayed to the user.

My format is slightly different than Paul Kenney's (www.pjk.us/pjk/blog/index.cfm? event=showEntryForID&entry=9603C7B2-3048-28E9-DAD333835BEAFD8A), but the result should be the same. Here is a complete example of an Application.cfc from a site that used to use Application.cfm and OnRequestEnd.cfm:


<cfcomponent>

<cffunction name="onRequestStart"><
  cfinclude template="Application.
  cfm"></cffunction>

<cffunction name="onRequest">
    <cfargument name="targetPage"
      type="string" required="true">
    <cfinclude template="#arguments.
      targetPage#">
</cffunction>
<cffunction name="onRequestEnd"><
  cfinclude template="OnRequestEnd.
  cfm"></cffunction>

<cffunction name="onError"
  returntype="void" access="public">
    <cfargument name="exception"
      type="any" required="true">
    <cfargument name="eventName"
      type="string" required="true">

    <cfset var Except = arguments.
      exception>
    <cfset var SessionExpiration =
      false>
    <cfset var redirectUrl= "/index.
      cfm">

    <cfif arguments.exception.
     rootCause eq "coldfusion.runtime.
     AbortException">
        <cfreturn/>
    </cfif>

    <cfif StructKeyExists(Except,"Root
      Cause") AND StructKeyExists
      (Except["RootCause"],"Detail")>
        <cfif Except["RootCause"]
         ["Detail"] CONTAINS "Session
         is invalid">
            <cfset SessionExpiration
              = true>
        </cfif>
    </cfif>

    <cfif SessionExpiration>
        <cfcookie name="JSESSIONID"
          value="" expires="NOW">
        <cfheader statuscode="302"
          statustext="Moved 
          Temporarily">
        <cfheader name="location"
          value="#redirectUrl#">
    <cfelse>
        <!--- Code to output text to 
          user and send email to site
          administrator goes
          here. --->
    </cfif>

    <cfreturn true>
</cffunction>

</cfcomponent>

This is the lazy route of leaving old code in Application.cfm and OnRequestEnd.cfm. I would suggest eventually moving the code around to take advantage of the structure of Application.cfc (hopefully more on that later).

Good luck!

Blog Topic: RIAs

RIA definition
By John Dowdell from "JD on MX"
(www.markme.com/jd)

The term "RIA" was used frequently this past month, but it was only while reading the piping-hot comments at a Scoble article (http://radio.weblogs.com/0001011/2005/03/21.html#a9714) about "Microsoft Outlook Web Access being one of the first and best AJaX apps," that I remembered there actually is a functional definition of Rich Internet Application.

It's contained within that RIA whitepaper Jeremy Allaire wrote for the Macromedia site in March 2002, which was the first use of that phrase on the web (according to searches later done at recall.archive.org, which has since disappeared).

I've copied the first section which describes some of the requirements for rich internet applications:

"In the mid-1990s, explosive growth in the Internet and the World Wide Web drove widespread adoption of a new model for content and applications using personal computers connected to the Internet. Coined "thin-client" computing, this new model promised to lower the cost of developing and delivering applications to end-user desktops, customers and business partners, and to increase the range of application types that could be delivered. This model centered on a very thin client based on HTML, and powerful application servers that dynamically composed and delivered "pages" to web browsers.

So far this model has proven successful. However, it has also suffered from significant drawbacks and limitations, especially around the richness of the application interfaces, media and content, and the overall sophistication of the solutions that could be built and delivered. Indeed, for many traditional application developers, while the web has offered significant conveniences in terms of ease of deployment, the capabilities of the programming and user interaction models have forced users to suffer. In many respects, much of the web application development and deployment technology of the late 1990s has had to adapt to the challenges imposed by the architecture inherent in the web.

The Internet of 2002 will be different. End-users and businesses are demanding more from their investments in Internet technology. The ability to deliver true value to users is forcing many companies to look towards richer models for Internet applications; models that combine the media-rich power of the traditional desktop with the deployment and content-rich nature of web applications. Companies are also anticipating a growth in the use of web services, or reusable software components that are used as services over the network, and looking towards a world where applications will need to share functionality and data across many types of client devices. These trends are driving the industry towards next-generation rich clients.

This is the backdrop upon which Macromedia built Macromedia Flash MX and Macromedia Flash Player 6. Before detailing the technical aspects of the Macromedia Flash MX client environment, it is important to note what we consider to be the crucial aspects of rich client technologies. Rich client technologies should:

  • Provide an efficient, high-performance runtime for executing code, content and communications. The principle here is that the end-user experience of HTML-based web applications suffers from a variety performance related challenges. These include the request-response page rendering model; the need to dynamically generate large blobs of text for transmission of simple data; the lack of client-side data storage; the inability to easily invoke and use remote business logic, and even the basic graphics model of HTML. These all must be improved.
  • Integrate content, communications, and application interfaces into a common environment. The end-user experience of the Internet today is fragmented into the HTML browser for textual content and basic application interfaces; multiple messaging clients for performing communications functions; and multiple media players for handling audio, video, and other forms of media. Rich clients need to provide deep integration for all of these types of interaction.
  • Provide powerful and extensible object models for interactivity. While web browsers have progressed in terms of their support for interactivity through the Document Object Model (DOM), JavaScript, and DHTML, they still lack the richness needed for building serious applications. Rich clients need to provide a powerful, object-based model for applications and events. This common object model must integrate user interface, communications, and system level services.
  • Enable rapid application development through components and re-use. Rich clients should support powerful component-driven development, enabling both third party and corporate developers to easily reuse visual components to accelerate development, and give junior developers access to complex functionality. These components should integrate seamlessly into the designtime environment for ease of development.
  • Enable the use of web and data services provided by application servers. The promise of rich clients includes the ability to cleanly separate presentation logic and user interfaces from the application logic hosted on the network. Rich clients should provide a model for easily using remote services provided by back-end components, whether hosted in an application server or accessed as XML web services.
  • Embrace connected and disconnected clients. While many users have gotten used to having to be online and in a web browser to perform work, the reality is that most applications would benefit from the ability to be used offline on occasionally connected devices such as personal digital assistants (PDAs) and laptops. Likewise, many applications require support for persistent connections with two-way, notification-based communications. Rich clients must enable both of these types of applications to be easily built and deployed.
  • Enable easy deployment on multiple platforms and devices. Internet applications are all about reach. The promise of the web is one of content and applications anywhere, regardless of the platform or device. Rich clients must embrace and support all popular desktop operating systems, as well as the broadest range of emerging device platforms such as smart phones, PDAs, set-top boxes, game consoles, and Internet appliances.
Macromedia Flash MX attempts to address and enable all of these opportunities."

Blog Topic: Aggregators

I Need a New Aggregator
By Christian Cantrell from "Christian Cantrell's Perspective"
(www.markme.com/cantrell)

An unfortunate thing happened to me this morning. I have an old evaluation of NetNewsWire installed alongside the free version of NetNewsWire Lite which I use(d) extensively on a daily basis. This morning, when using Quicksilver to open NetNewsWire Lite, I accidentally opened the old expired evaluation version of NetNewsWire. For some reason, it overwrote all my NetNewsWire Lite feeds with the default list of feeds that come with the application.

This is very much not a good thing. I'm sure I had well over 100 feeds pertaining to everything that interests me (mostly technology, but also some personal weblogs, watch weblogs, etc.). I have a backup from November that will allow me to recover many of my feeds, but my collection was constantly evolving and being refined, so the last four months of tweaks are gone.

Anyway, enough lamenting. I'm looking at this as an opportunity to start fresh with a new collection of feeds, new organization, and certainly a new aggregator. I really like(d) NetNewsWire, but I don't think I can bring myself to use it again. Additionally, I'm tired or waiting for the 2.0 version just to get Atom support (it's been in beta for a very very long time).

So my first question is what aggregators are Mac users out there using these days? I'm willing to go with either local or web-based. Once I settle on a new aggregator, I will then ask people to post some of their favorite blogs. I'm pretty sure I can have all my old feeds back with a couple of hours of searching and surfing, but I'd like to use this opportunity to find some new, more obscure feeds worth aggregating. That's a question for another time, though. First the aggregator.

Blog Topic: New Flash Book

Flash Anthology
By Dave Yang from "swfoo"
(www.swfoo.com/)

SitePoint sent me Flash Anthology - Cool Effects & Practical ActionScript by Steven Grosvenor and asked me to write a review.

The back cover of the book says "best practice solutions to common Flash problems," which led me thinking it was a book on design patterns. However, in the "Who Should Read This Book?" section, it says the book is aimed at beginning and intermediate Flash developers and designers. The book is not for learning Flash MX 2004, ActionScript, OOP, or design patterns.

Instead, the book focuses on using ActionScript 1.0 "to achieve extensible, adaptable, and aesthetically pleasing results." There are over 60 ActionScript solutions, covering 10 chapters: Flash Essentials, Navigation Systems, Animation Effects, Text Effects, Sound Effects, Video, Flash Forms, External Data, Debugging, and Miscellaneous Effects.

I was a bit surprised to see no ActionScript 2.0, typed data, classes...etc., from a book published almost a year after Flash MX 2004 was released. Instead, I see most examples dealing with the prototype , scattering of _root , capitalization of method names in one section and lowercase elsewhere...etc.

To be fair, not all Flash projects require ActionScript 2.0, OOP or patterns. In fact, I'd think most typical Flash projects are still one-offs that have short life cycles. As Branden Hall says, sometimes pragmatic programming can be an ideal solution, especially for these quick one-off projects. Perhaps this book is for beginning Flash designers who work on small projects. SitePoint offers 30 days, risk-free, money back guarantee; so I guess it's worthwhile to give it a read if you're a beginner designer looking for ActionScript to create cool effects.

On a side note, for ActionScript 1.0 and effects, I'd suggest Robert Penner's book (www.robertpenner.com/) as an example of best practices.

Blog Topic: Flash

Make the World a Better Place with Flash
By Owen van Dijk from "MX Traveler"
(http://ohwhen.typepad.com/)

Did you know that on your birthday 24.000 people will die of hunger and hunger-related causes? Last year I was involved with a special project that was part of the worldwide awareness-raising campaign First8. The heart of the campaign was a pocket-sized photography book with powerful portraits of people living and surviving in difficult and unacceptable circumstances throughout the world.

In September 2004 this book was delivered by mail to 25,000 people in positions of power and influence, addressed to each individual personally, by name. As the campaign was anonymous, there was no return address, only the address of this website. In the Netherlands, 1.6 million copies of this book, in mini-magazine format, were distributed along with various magazines. The book carries only this text:

Today you are one of more than 25,000 heads of state, ministers, members of parliament, monarchs, religious leaders, captains of industry, journalists and other influential people of 191 countries who hold this printed glimpse of our world.

For the first time in history we have the means to end poverty.

Today it's in your hands.

(www.first8.org)

There was no return address: the sender of the book was anonymous. The recipient was being asked to think about his or her own responsibility in the world: What can you do, using your position or status?

It also was a confrontational address to the members of the United Nations on the eve of the UN General Assembly in New York on 21 September 2004; a call to make an extra effort in the battle against poverty and to stick to agreements made in 2000, the Millennium Development Goals:

  1. Eradicate extreme poverty and hunger
  2. Achieve universal primary education
  3. Promote gender equality and empower women
  4. Reduce child mortality
  5. Improve maternal health
  6. Combat HIV/AIDS, malaria and other diseases
  7. Ensure environmental sustainability
  8. Develop a global partnership for development
I'm proud to be part of this project, and the whole team worked hard to translate the message from the book to an online experience. At the end of last year, this project won a prestigious advertising award; a Golden Epica (www.epica-awards.com/). The Epica awards are European prize for advertising and marketing-communication in film, print and on the web. Entries are judged on two critera: originality of the creative concept and the quality of the output.

Although it's always nice to win such a prestigious award, the real reward is the attention that comes with it for the actual website. I'd like you to take 5 minutes and have a look at the website (www.first8.org/first8.html) and think about your responsibility to make this world a better place.

More Stories By Adobe News Desk

MXDJ News Desk gathers stories, analysis, and information from around the world of software design and development and synthesizes them into an easy to digest format for MX developers.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.