Driscoll Web Development Blog

Get information, tools, news, tips, and more from the expert web developers at Driscoll Web Development.


Friday, January 16, 2009

Creating a Read-Only Numeric Stepper Component in Flash/Actionscript 2.0

While working on a project recently I spent some time getting to know the Numeric Stepper component. Anyone who has worked with the component most likely knows about its most obvious shortcoming: the text field within the component is read/write! Of course, the actual value associated with the component only changes in response to events fired by the Mouse or Key (up/down arrow) objects, but nonetheless our client wasn't happy with the fact that a user could type in the text field.

So, I set about trying to make the text field read only. Based on my research I gathered quickly that this has been attempted before with varying results. One of the key issues that makes the proposition of "tweaking" a component difficult is the fact that a component class cannot be subclassed; otherwise, it would be fairly straightforward to create a new class that inherits from NumericStepper and simply add the necessary properties and methods to support read/write and read only modes for instances derived from the subclass.

With subclassing out of the question most of the developers' blogs I encountered suggested overriding methods of the mx.core.mx_internal namespace (from which the enabled property of the NumericStepper.inputField object is derived), however that's a bit cumbersome and a complex solution to what seems to be a relatively straight-forward problem.

Luckily for me, I've been playing around a bit with coding ActionScript Communication scripts, which are (more or less) ActionScript 1.0 scripts. In these scripts, the "easy" way to add properties and methods to a built-in class is to use the prototype object (i.e.: ClassName.prototype.someNewFunction = function(){...}). With that concept in mind I tried to see if I could use the prototype object to extend the capabilities of my NumericStepper component... and it worked! What follows is the code that allows you to do this for yourself:

1. Create a new Flash document.
2. Open the Components panel and drag two instances of the NumericStepper component onto the stage. Give the two steppers instance names of "myStepper1" and "myStepper2", respectively.
3. Add the following code to the Main Timeline of your document:

So, what does this code do, exactly? Well, the draw() method overrides the draw() method of the NumericStepper class. The only "new" functionality we've added is within the if-block; we test the instance's editable property, and if that property has a value of "false" then the component's text field is disabled. Otherwise, the text field is enabled (which is the default). All of the code that follows the if-block is the same as the NumericStepper's native draw() method.

The next two functions, setEditStatus and getEditStatus are simply getter/setter functions for the editable property.

Finally, I register the editable property with the component using the AS1-style addProperty method.

That's all there is to it! Now, to see this new property in action simply create a new layer on your main timeline and add the following code:

myStepper1.editable = true;
myStepper2.editable = false;

Go ahead and test out your movie. One instance (myStepper1) should have an editable text field, while the other (myStepper2) should not.

Happy coding!

(Download the source script for the extended NumericStepper here: http://blog.driscollwebdev.com/NumericStepperExtension.as)

Labels: , , ,

Monday, February 18, 2008

Is Your Registrar's Multi-year Deal Worth It?

Almost every domain name registrar out there is offering a deal these days: pay up front to register your domain name over a multi-year period and save money. The question that my clients and colleagues alike invariably ask is whether or not these deals are worth it.

My answer: Maybe.

Realistically, whether or not a multi-year registration is worth the cost depends on a lot of variables. For instance, the first question I ask is "Will you still have a website in 5 years? What about in 10?", and, "If so, do you think your business' name will be the same as it is now?"

Usually the blank stare is enough to tell me that a 10 year deal is probably not a good investment. But let's assume for a second that my client knows for sure that her online venture will still be up and running 5 or 10 years from now. Is it still a good deal? Well, then it all comes down to finances.

Common Knowledge and Misconceptions
Of course it's your registrar's duty to make you think that you're making out like a bandit when you opt-in to a multi-year deal, which is why it likes to tell you what percentage you're saving if you take the multi-year option: "Save 50% with a 10 year plan!"

50% of what? Indeed, that is the question. By making some quick calculations it's usually pretty easy to see that you're saving when compared to 10 years at the full price (whatever that may be). What your registrar doesn't want you to know is that you may not be saving as much as you think.

Anyone who has been subjected to a collegiate finance course can tell you that $1 is worth more in the future than it is today. How is that possible? Well, imagine that you have $1 right now, and you put it into a high-yield savings account that has a 4% annual yield. A year from now your $1 will be worth $1.04. Hence, your $1 will be worth 4 cents more a year from now than it is today.

We can use a similar approach to figure out what $1 in the future is worth today. Again, let's imagine that the current annual interest rate on a high-yield savings account is 4%. We would like to know how much to deposit today in order to have $1 a year from now.

$1/1.04 = $0.96*
(*rounded to two decimal places)

So, we'd need to deposit 96 cents into our high-yield savings account in order to withdraw $1 a year from now. $0.96 is the present value of $1 in one year if the current interest rate is 4%.

Multi-year Discounts and Present Values
Now let's use what we know about present values to determine whether or not we're getting a good deal.

As of today, Register.com is offering multi-year registration of top-level domains at the following prices:

1 year: $35
2 years: $70
5 years: $149
10 years: $249

Clearly, the alternative to purchasing one of these packages is to simply pay the regular price of $35 per year. But, as we already know, $35 is worth less today than it will be in the future, so we need to know what the present value of making a $35 annual payment is over several years, keeping in mind that we'll be making our payment at the start of each annual period. The current annual yield of a business savings account with ING Direct is 3.75%, so the present value of $35 paid annually with an interest rate of 3.75% is:

1 year: $35
2 years: $68.73
5 years: $162.80
10 years: $298.23

From this we can see a few things:
  1. We will indeed save money if we opt for the 5 or 10 year plan. However, we are not saving as much as Register.com would like us to believe (for instance, we're really only saving $49.23 rather than $101 by going with the 10 year plan).
  2. We actually lose money by taking the 2-year plan.
Point #2 is important to note, as most of us would simply think that paying $70 for 2 years up-front is the same as paying $35 now and $35 a year from now, but it is not. Instead, we could pay $35 now and put $33.73 into a high-yield savings account earning 3.75% interest. In a year we'd have $35 which we could use to pay for another 1-year contract. Thus, our second year really only costs $33.73 rather than $35.

Deal or No Deal
In this case we see that the longer-term deals (5 and 10 years) with Register.com are certainly money-savers right now, but will they always be? Maybe, maybe not.

In our analysis above we assumed two things:
  1. The annual registration fee will remain constant at $35 over the next 10 years.
  2. The annual interest rate of our high-yield savings account will remain constant at 3.75% over the next 10 years.
If both of our assumptions remain true over the next 5 or 10 years, then we know that we've saved money by taking the multi-year deal. But what if we take the multi-year deal and one (or both) of our assumptions prove to be false? Let's find out what happens...

What happens if the annual registration fee changes?
If we take the multi-year deal and the registration fee changes then we may not have made a good deal. If the annual fee goes up, then clearly we'll have saved even more than we'd initially thought over the contract term. However, if the annual registration fee goes down, then it's certain that we're saving less than we initially thought, and it's possible that we're actually losing money over the course of the contract. It all depends on how much the annual fee goes down and how far into the contract term we are. Generally speaking, smaller price changes will have a greater impact earlier in the contract than they will later.

What happens if the annual savings yield changes?
Similarly, if we take the multi-year deal and the annual yield of the savings account changes, then it is possible that we've not made a good deal. Generally speaking, if the interest rate goes down then we'll have saved more money with our long-term contract than we initially thought. But, if the interest rate goes up then it's certain that we're saving less than we initially thought, and it's possible that we're actually losing money. Again, this depends on how much the interest rate goes up and how far into the contract term we are. And, just like price changes, smaller interest rate changes earlier in the contract will have a greater impact than the same changes later in the contract.

What happens if both the interest rate and the registration fee change?
Once again, the extent to which our potential savings is affected depends on how much each changes. If the interest rate goes up AND the registration fee goes down, then the two effectively compound and we'll have saved far less money than we initially thought when we signed the multi-year contract. However, if the interest rate goes up but the registration fee also goes up (or if they both go down), then it's possible that the two changes will simply cancel each other, and the net savings will be comparable to the deal we had initially.

Other Risks of Multi-year Deals
There are certainly other risks associated with multi-year domain registration contracts that go beyond interest rates and registration fees. Chief among your concerns should be the longevity of your potential registrar, however there are other things to consider as well. Be sure to read your contract carefully, as there may be additional fees incurred for certain services, and the terms of the contract might make it painfully difficult and costly for you to get out of the deal if it goes south (or if you find a better deal...).

At the end of the day, the question of whether or not you should engage in a multi-year domain name registration will depend largely on your firm's goals over the next 2 to 10 years, while the financial implications of a long-term deal may not be the first thing that comes to mind. Nonetheless, it is important to take those financial concerns into consideration! If you're unsure about it right now, stick with a yearly renewal plan. After all, you can always decide at a later date to go with a long-term commitment.

Labels: ,

Saturday, February 2, 2008

It's a Web 2.0 World, baby, and you'd better get on the bus now before you (and your revenue generating properties) miss out!

You're a small business owner. Your business has a website. You have children.

You could learn a thing or two from your children about how to make the most of your company's presence on the web.


First, an aside: you've probably heard about this whole "Web 2.0" business the last couple of years. But how many times have you heard it defined? Do you really know what Web 2.0 is? Do you know what it stands for?

In its simplest sense, the term Web 2.0 simply conveys the message that the World Wide Web has come a long way since its humble beginnings. From a developer's perspective, Web 2.0 defines websites that are standards-compliant and optimized for interoperability (there's a lot that goes into both aspects, but we'll skip that for now). From a user's perspective, Web 2.0 defines the ability to create and share content from multiple sources, whether it be a blog, a news feed, photos, music, or just about anything else that can be served up online.

It's probably no big surprise that the 18-24 demographic represents the largest proportion of visitors to Web 2.0 sites like YouTube, Flickr, and Wikipedia according to Hitwise, a market data research firm that specializes in internet marketing. Further, research from Avenue A | Razorfish suggests in its Digital Consumer Behavior Study that 55% of online consumers rely on user reviews to determine whether a product or service is worth purchasing.

Of course, many big companies have taken advantage of the opportunities to reach the wide audiences of the aforementioned sites, as well as social networks such as MySpace and Facebook. Smaller outfits that lack the advertising budgets of the retail giants have used sites like YouTube, MySpace, Facebook, and Flickr to their advantage by creating profiles, uploading "soft" ad videos, uploading photos of new products (or even better, uploading photos of people using those products), and creating social groups around their products and services. And, many companies have also managed to attract a following of Friends on social networking sites.

The true advantage of these types of sites is that they allow users to leave comments for other users pertaining to photos, blog entries, videos, you name it... so, it's likely that a user who has purchased a product from a certain company will leave a comment for that company on its social networking profile. And, it's likely that the comment will be an ad-hoc review of the product. With the assumption that the review is positive, this will serve effectively as a public endorsement for your product. Collect a few such comments, and don't be surprised when traffic to your company's website begins to pick up.

Of course, in order to take full advantage of all the marketing opportunities that this Web 2.0 world has to offer, you have to have the time and ability to create your own user-created content on Web 2.0 sites. This is where your kids (or your neighbor's kids) come in: chances are that they are well-versed in the lingua franca of these sites already, and they could probably give you quite a tutorial.

-DWD Staff

Labels: , , ,

Friday, November 30, 2007

4 Ways to Keep Your Forms Safe

It's every webmaster's deepest fear, and as developers we hear about it more and more each day: brute force attacks on online forms that litter websites, databases, blogs, forums, and inboxes with unwanted Spam. From the webmaster's perspective it's both tedious and costly to remove database records and blog/forum comments that promise everything from free Viagra to... well, things we won't even mention here. And, not only do these Spam attacks cause eyesores in visual content, they also eat up bandwidth and storage space - both precious commodities these days.

Here are some ideas for webmasters and web developers to implement in order to keep their forms from becoming targets for Spam attacks.

1. Validate Form Input on the Server
This seems like an obvious step to take, but there are still so many websites out there that do not implement server-side validation of form input. Web developers often complain that server-side input validation impedes usability and page flow by adding an additional step to the form-filling process, but the rise of AJAX has rendered that complaint all but obsolete. Current technologies such as AJAX make communicating with the server in real-time (as the form is being filled) possible, thus form inputs can easily be validated on the server without causing headaches for the end-user. We recommend using Regular Expressions to search for unwanted input.

2. Implement CAPTCHA Verification on Your Form
CAPTCHA, short for "Completely Automated Public Turing test to tell Computers and Humans Apart", is quickly becoming the de-facto standard for protecting forms against brute force attacks. The method typically involves the use of an image that contains heavily distorted text on a "noisy" background (see image below). The way in which the image appears prevents computers from successfully solving the problem of identifying the character sequence, however to a human it's easy to see that the words are "following" and "finding."

We subscribe to the DRTW principle when it comes to this topic, so we highly recommend implementing a third-party CAPTCHA solution on your form rather than trying to code it yourself (freeCap, available from pureMango, is our favorite). However, if you're really in an ultra-nerd mood and want to see how it's done, we recommend taking a look at this article.

3. Make Your Form Un-searchable
If the page that contains your form shows up in search engine results, you're pretty much asking to be spammed. There are four things that you can do to get your forms out of search engine results:
  • Add a <meta> tag to the <head> of the page to keep search engines from indexing your form page.
  • Create a robots.txt file and upload it to the root directory of your web server to keep search engines from indexing your form page.
  • Remove all <url> elements from your sitemap that contain references to your form page.
  • Request that the specific URL for your form page be omitted from search results (See Yahoo! SiteExplorer and/or Google Webmaster Tools for more information on this).
Of course, many webmasters and business owners bristle at the idea of making their forms "invisible" to the eyes of potential visitors, but in our opinion the benefits of doing this outweigh the risks of being spammed.

4. Make Your Form Load Dynamically
The idea of loading page content dynamically from a database or script when the page loads is certainly not a new one. However, when it comes to forms, most developers hard-code form elements into the page. A dynamically loaded page is nearly impossible to cache, making it nearly impossible for attackers to find (the attacker's user-agent would have to load the page in order to discover the form).

It is difficult to guarantee the safety of online forms against malicious attacks. As much as we use new technologies and coding practices in our work, those who seek to do us harm are learning those same technologies in an attempt to find ways to exploit them. So, while these 4 tips will help you a great deal to keep Spam attacks from occurring on your website, you should always be looking for new and different ways to secure your form from attacks.

-DWD Staff

Labels: , ,