The M in MVC: Why Models are Misunderstood and Unappreciated

I've been writing a book about the Zend Framework recently - I'm sure some of you have noticed . A while back I finished a draft of two chapters called "The Architecture of Zend Framework Applications" and "Understanding The Zend Framework". The first chapter is an exploration of the Model-View-Controller (MVC) architectural pattern and why it has become the defacto standard for adoption in web applications. The second explores how the MVC architecture relates to the Zend Framework's components, their design and interactions.

By the time I'd finished both chapters I realised I had spent a lot of space explaining the Model, most of it discussing how the Zend Framework does not actually give you one. In fact, no web application framework offers a complete Model (for reasons I'll explain later). However nearly all frameworks manage to avoid making that perfectly obvious. Instead they continually link the concept of a Model to the related, but not identical, concept of data access. This is quite misleading.

This side of frameworks never gets a lot of attention. Yet it is a massive contributor to a whole class of problems in applications which attempt to utilise MVC by adopting web application frameworks. Further, I've always found myself better entertained by banging my head against brick walls than by trying to get the idea of a Model across to other developers. I'm not saying all developers are stupid or dumb, or that they don't get the concept in general, but all developers (PHP or not) don't quite link Models to the area of practice which justifies them - Object Oriented Programming principles.

In this entry I explore Models in terms of how developers relate them to Controllers and Views in applications and note a few strategies you can employ when using proper Models.

Models Misunderstood
The Model can be explained a few ways. In fact, you can write entire books about just the Model and many people have! The Model generally has two roles broadly defined:

1. The Model is responsible for maintaining state between HTTP requests.

Basically any data whether on a database, in a file, stored in the Session, or cached inside APC must be preserved between requests and thus forms part of the state of the application at the time the last request was completed. So always remember that the Model is not just the database. Even the data you get from web services can be expressed as a Model! Yes, even Atom feeds! Frameworks which rattle off introductions to the Model, almost never explain this upfront which only exacerbates misunderstandings.

Here's an example, while it's called Zend_Feed_Reader that new component which I'm developing is actually a Model. It reads feeds, manipulates them, interprets data, adds restrictions and rules, and generally creates a usable representation of the underlying data. Without it, you have Zend_Feed (the current top dog in feed reading) which requires lots of additional work to develop it into a viable Model. In other words, where Zend_Feed_Reader is a partial Model, Zend_Feed is pure data access.

2. The Model incorporates all the rules, restraints and behaviour governing and utilising this information.

For example, if you wrote business logic for an Order Model in an inventory management application, company internal controls could dictate that purchase orders be subject to a single cash purchase limit of €500. Purchases over €500 would need to be considered illegal actions by your Order Model (unless perhaps authorised by someone with elevated authority). The Model should be capable of enforcing this.

This makes incredible sense if you examine the meaning of the word "model". We have climate models in climatology, for example, which define the data, run processes, assume behaviours and calculate probable outcomes from these. The M in MVC is called a Model for a reason. The Model doesn't just represent mere data, it represents the entire system for which that data is useful. Of course any system can be complex enough to require multiple interacting Models but you get the idea.

If you read these two points, you may realise something startling. With the exception of the UI, most of any application can be expressed within Models. It's the Model that centers on all the data and underlying behaviour of that data, and sometimes even how to display that data. It's the Model which can understand, interpret and represent that data and provide it with meaningful uses.

In Programming, Fat Models Are Preferable To Size Zero Models
Jamis Buck (the author of Capistrano now employed by 37signals) once wrote about a concept called "Skinny Controller, Fat Model" (our own Chris Hartjes wrote a blog entry on the same topic). I've always liked the simplicity of this concept since it illustrates a key facet of MVC. In this concept, it is considered best practice to maintain application logic (like our business logic from above) within the Model as much as possible and not in either of the View or Controller.

The View should only be concerned with generating and presenting a UI so users can communicate intent to the Model. Controllers are the orchestrators who translate UI inputs into actions on the Model and pass back output from whatever View has been made aware of the Model(s) its presenting. Controllers must define application behaviour only in the sense that they map user input onto calls in Models, but beyond that role it should be clear all other application logic is contained within the Model. Controllers are lowly creatures with minimal code who just set the stage and let things work in an organised fashion.

PHP developers, by and large, don't fully understand what a Model is. Many see the Model as a fancy term for database access and others equate it with various design patterns for database access like Active Record, Data Mapper and Table Data Gateway. This is the misconception frameworks often promote, unintentionally I'm sure, with abandon. By not fully comprehending what a Model is, why it's such a great idea, and how one should be developed and deployed, developers unintentionally kick themselves into a dark path which leads into what can only be described as poor practice.

Here's a thought exercise to get you thinking. Imagine you just built the finest web application imaginable using the Zend Framework. Your client is incredibly impressed and their praise (and fees) are most welcome. Unfortunately they forgot to mention that their new CTO is insisting all new applications utilise Symfony and they'll offer you a nice shiny cheque if you'll convert your application over for them. The question is - how easy will that be? Think about it for a moment...

If you have your application logic bound up in the Model - then celebrate. Symfony, like many (but not all) frameworks, accepts Models regardless of what they are written on top of. You can port your Model, its unit tests, and its supporting classes with little to no modification into Symfony. If you stuck it all into Controllers, start feeling worried. Do you think Symfony can use Zend Framework controllers? Do you think those functional tests using the Zend Framework PHPUnit plugin will magically keep work? Ta-da. That's why Controllers are not a substitute for Models. They have minimal reuse.

Unappreciated, Underestimated, Unloved: Depressed Models
Since developers often demote Models to mere database access as supplied by default in 99.9% of frameworks, it's no surprise they are unimpressed by the theoretical ideals attached to them. By focusing and obsessing about data access, developers completely miss one important factor: Models are classes which are not coupled to the underlying framework. They have no expensive setup - you simply instantiate and use them.

Maybe we can't blame the average developer though. Web applications do have a certain behavioural pattern which makes that crooked path more attractive - lots of them are just big data readers. If there is little data manipulation, only data reading, then any Model will look similar to plain old reliable data access. It's unfortunate in a way, but don't let the simplicity of reading data fool you. Not all applications are going to be read only - some will no doubt have something to do with that data besides displaying it raw and unchanged from the database

Models are the underdog in PHP. Views have captured everyone's imagination since the advent of Smarty and it's brethren. Controllers make almost as much sense since they read from databases, and pass any retrieved data into templates (a common interpretation of VC). Yep - Controllers are the logical evolution of the mentally ingrained Page Controller approach every PHP developer and their dog has used since PHP3. At least - that's the obvious conclusion for most. We'll bust the "Controller = Page Controller" myth later.

Models though. Models don't have the same ideological attraction or similarity to old habits which is why people pass them over and use "data access" as the underlying meaning. You know, like references in PHP pointing to the same value in memory? The language has changed but the same old ideas are still in play behind the scenes, strumming their discord in our neural nets.

But wait...developers do write functioning applications! So if they are not using Models brimming with application logic, what the hell are they using?!

Fat Stupid Ugly Controllers: SUC It Up
Since Models are so lame to developers, they invented a new concept. Fat Stupid Ugly Controllers (FSUC). I put the SUC in FSUC on purpose. It seemed funny at 10pm after a few drinks . And less offensive than FUC. These were invented since Models were strange, alien, and possible terrorist entities nobody really trusted with anything other than data access methods.

The average FSUC reads data from databases (using a data abstraction layer developers like to pretend is a Model), or manipulates, validates and writes it, and passes other data to the View for rendering. It's incredibly popular. I'd say most people using frameworks create them as naturally as they ever did Page Controllers. They are popular because developers have figured out that they can treat Controllers almost like Page Controllers which requires little change from their historical practice using single PHP files for every application "page".

Notice something odd? The FSUC is performing all sorts of actions on data. Why? Because without a Model, all the application logic must go into the Controller, which makes the Controller - a type of Mutated Model! I use "Mutated" with reason. FSUCs are big, unwieldy, ugly looking and definitely fat. The quasi programming term that applies is "bloated". They perform roles they were never intended for. They are a complete reversal of everything you are taught to do in applying Object Oriented Programming principles. They are also pointless! Developers, for some mysterious reason, seem to prefer FSUCs to Models despite the fact those Controllers really are just Mutated Models.

Remember our thought exercise? If you put everything into Controllers, you will never be able to efficiently migrate an application to another framework. This type of tight coupling is the kind of thing Kent Beck fans are supposed to identify as a "code smell" in Refactoring. But it's not the only smelly artifact of FSUCs. FSUCs are big, with massive methods, multiple roles (one per method usually), massively duplicated code, lacking refactored external extracted classes and...they are a nightmare to test. With many frameworks, you can't even properly apply Test-Driven Design (TDD) on Controllers without writing custom plugins and being forced to manage request objects, sessions, cookies, and Front Controller resets. Even then you have to test the View it creates because Controllers don't have output independent of Views!

So keep asking those questions! How do you test a Controller? How do you refactor a Controller? How do you limit the role of a Controller? What is the performance of a Controller? Can I instantiate a Controller outside the application? Can I chain multiple Controllers in a single process and still remain sane? Why am I not just using simpler independent classes and calling them Models? Am I considering these questions at all?

Models Are Inevitable (Like Taxes And Death)
FSUCs make the classic mistake. By assuming a Model is a silly idea and plain old data access works best, developers unwittingly stick application logic into Controllers. Yes - congratulations. You just created a Model, a butt ugly Mutated Model you insist is a Controller. But this pretend Controller isn't easily portable, testable, maintainable, or refactorable (assuming refactorable is a real word...might be!). The nature of Controllers is such that they are tightly coupled to the underlying framework. You can only make a Controller execute by initialising the entire framework's MVC stack (potentially dozens of other class dependencies!).

Either way you try to go - you end up writing the application's logic somewhere. Putting it in a Model, away from the Controller, simply creates lots of classes which are independent of the framework you're using. Now you can test those buggers all day using PHPUnit without ever seeing a Controller or View in sight or having to torture yourself silly trying to make the entire framework stack reset after every test, and by seeing them as real classes with specific roles you can also put yourself in the right mindset to apply proper refactoring and create real maintainable code without duplicating code across multiple classes.

Models are inevitable. One can call that FSUC a Controller, but it's really a Controller+Model - an incredibly inefficient Model replacement. Someone just shuffled the source code around while laughing at all the fools talking nonsense about the importance of good independent domain models. Well, laugh back. They're the ones who have to test and maintain their mess.

This is really where most web application frameworks let their users down. They are surrounded by a lot of marketing garbage which subtly suggests that they offer a full Model. Have you ever seen a framework say anything different in an obvious way? Afterall, they are MVC frameworks. If they are forced to admit the M is something developers will have to create themselves, it might look bad. So they bury the truth in the documentation scattered throughout their data access feature, if they mention it at all.

In reality, they only offer data access classes - the real Model is something that's application specific and must be developed independently by the developer after discussion with clients (you can pick your buzzword practice to achieve that - I'm into eXtreme Programming (XP) personally). It needs to be tested, validated, updated and you face the same probability of failure/success regardless of what framework you use. A bad application in Rails will still make a bad application on Code Igniter.

Controllers Should Not Guard Data
The other facet of this lack of Model consideration is that when developers are convinced that Models should be used minimally, it reinforces a reliance on Controllers to take on a new role as Data Gatekeepers (a large reason why they mutate into FSUCs). Want some more opinionated fuel to fire up everyone disagreeing with me right now?

A while back when I was writing the proposal (Zend_View Enhanced) that would eventually be adopted into the Zend Framework to create an object oriented approach to generating complex Views, I started moaning about Controllers being used as the sole method of getting data from Models into Views. My own thoughts were that Views could skip the middleman and instead use View Helpers to read data from Models more directly. This would support an architecture where in many read-only page requests, your Controller Action would be...empty. Devoid of all code. Nada.

In my mind, the best Controller is a Controller which doesn't need to exist .

I was immediately treated to a mass of resistance. Few people seemed to understand that an empty Controller, with all Model interaction extracted into simple reusable View Helpers, would reduce code duplication in Controllers (lots of code duplication!) and avoid the necessity of chaining Controller Actions. Instead there was lots of muted puzzled expressions. Most people simply assumed that MVC worked as follows: requests go to Controllers, Controllers get data from Model, Controller gives Model data to View, Controller renders View. In other words: Controller, Controller, Controller, Controller. At one point I remarked that the entire community was obsessed with Controllers . It's still tough going just to get anyone to give Views data objects, let alone let them read directly from Models...

Note: Not to sound like a complete pratt - some people did get the idea .

None of the objections really caught on that this was an old idea. Java coined the term View Helper years ago as a design pattern in J2EE showing how View Helpers could assist Views in accessing Models (only on a read only basis since any writing should go through a Controller!) without the intermediary Controller. In MVC, there is every indication that Views should know about the Models they are presenting. Not just whatever arrays we decide to spoon feed them from Controllers.

So go further! How many Views only need one Model? A lot of my Views use several Models, with highly repetitive Model calls. A View Helper is a single class - but adding these repetitive calls to Controllers, means you need to duplicate calls into multiple methods!

One crazy solution created to outwit the View Helper, is often to reimagine Controller Actions as reusable commands. Whenever a View needs several Models, you just call several Controllers in sequence. This concept is something I call Controller Chaining - its premise is to create supporting code to make reusing Controllers possible. You can translate that as: reusing every class needed to execute a single Controller Action. Remember - you can't use any Controller without initialising the entire framework . Though there are (there always are!) some exceptions.

Models are Classes, Controllers are Processes
I'm running thin on quickie ideas, but I mentioned Controller Chaining and it bears further examination. Chaining is used either to access multiple Models, or to merge the results of multiple Views, or both. Usually both - Controllers nearly always access Models and pass data into Views when you are not using View Helpers to shortcut the process.

Imagine you create three Controllers, each of which generates a View. To build some new web page, you need to merge all three Views into a single template page (or Layout). This is accomplished by telling Zend_Layout (or some other alternative solution for aggregating Views into common layouts/segments) to call all three Controllers sequentially. Now consider what is happening - three Controllers means you are making three dispatches into the MVC stack. Depending on the application this can pose a significant performance cost. Symfony, to illustrate how real that cost can be, uses "Components" as a specialised Controller type just to offset this performance hit but the Zend Framework has no equivalent. Rails has a similar idea which is rife with complaints about performance hits. The prevailing wisdom across frameworks is that using multiple full Controllers is horribly inefficient and a last resort when no other reuse strategy is available.

I'll say it again - Controller Chaining is a code smell. It's inefficient, clunky, and usually unnecessary.

The alternative is obviously to just use View Partials (template snippets capable of being merged into a single parent View) which can directly interact with Models using View Helpers. Skip the Controllers entirely - afterall they have no application logic unless translating user input into relevant Model calls (unless FSUCs ).

This highlights that Models are just a collection of loosely coupled classes. You can instantiate and call them from anywhere - other Models, Controllers and even Views! A Controller, on the other hand, is a tightly integrated cog in the machinery of a whole process. You can't reuse a Controller without also dragging in the entire process of setting up request objects, dispatching, applying action helpers, initiating the View, and handling returning response objects. It's expensive and clumsy in comparison.

Signing Off
There is a fast paced urgency to this article you'll have noticed. I'm a self confessed nut about applying the principles of elegant Object Oriented Programming to MVC frameworks. It's why I went all out with Zend_View Enhanced and saw it adopted, debated, and adapted with great success, into the Zend Framework. A lot of that is owing to Matthew Weier O'Phinney and Ralph Schindler who joined that parade. If we lose sight of simple OOP practice and principles, and get lost in trying to fight MVC into submission, the plot ss quickly lost. The MVC is a great architectural pattern - but at the end of the day our MVC interpretations and ingrained beliefs are all subservient to OOP principles. If we forget that, we do Bad Things™.

Hopefully this torrent of ideas about the Model in Model-View-Controller is somewhat enlightening and makes you think. Thinking should be your goal - question everything, and rebel when you feel something going wrong. If we run around on blind faith than we deserve everything coming to us .

Referencias
Food for thought: utilizing models in MVC
“What is a model” and “Is Zend_Db_Table a model” seem to be asked once in a while on #zftalk. Frameworks say they have a full model available, thus they are MVC frameworks. ORM libraries say they generate models. It seems the A...
Weblog: CodeUtopia
Tracked: Dec 06, 12:15

Das M im MVC-Entwurfsmuster
Ich habe vor einiger Zeit einmal über die nicht vorhandene Komponente Zend_Model geschrieben und dort den Stand der Dinge aus meiner Sicht zusammen gefasst. Das Kapitel zum Thema Models in meinem Zend Framework Buch ist bereits fast 20 Seiten lang und...
Weblog: Ralfs Zend Framework und PHP Blog
Tracked: Dec 09, 21:14 Sphere: Related Content

How to Design Programs

An Introduction to Programming and Computing by Matthias Felleisen, Robert Bruce Findler, Matthew Flatt, Shiram Krishnamurthi
(September 2003 Version, The MIT Press)

This is the first update since the third printing by the MIT Press. This release corrects mistakes and typographical errors in the first three printings.

The Book the complete text
Solutions solutions to all exercises, for teachers only !??!
Problem Sets additional problem sets not found in the book
Companion hints on how to use DrScheme
Teachpacks if you encounter bugs in your Teachpacks
Known Mistakes known typos and mistakes
DrScheme programming environment
TeachScheme! our educational outreach effort
Mail how to reach us Sphere: Related Content

The Schematics Scheme Cookbook

The Schematics Scheme Cookbook is a collaborative effort to produce documentation and recipes for using Scheme for common tasks. See the Book Introduction for more information on the Cookbook's goals, and the important ContributorAgreement statement.

Cookbook Starting Points
• Table of Contents (with recipes)
• Getting started with PltScheme
• The FAQ answers common questions about the Cookbook
• Common Scheme idioms
• Getting started with macros
• Using strings
• Using files

Editing Pages
•Register as an author
•Information on TWiki the software running this site.
•AuthorChapter -- A guide to contributions

Other Popular Pages:
The following pages are autogenerated:
•RecipeIndex - Recipes by chapter (similar to TOC).
•ParentTopics - List of Chapters & Sections
•AllRecipes - List of all recipes
•LibraryIndex - List of external software libraries

Administrative Pages
•AdminTopics - Summary of all administrative topics
•CookbookBrainStorm - ideas for the structure of the cookbook.
•ToDo - items to be done (a very incomplete list)
•RecipeStubs - Recipes that need to be written or completed
•HelpNeeded - Pages with markup problems
•OriginalCookbook - links to a converted version of the original cookbook
•RecentSiteChanges (last changed 09 Apr 2007 - 00:15)
•SectionIndex - This page has errors but somebody may want to fix it.

Notes:
•You are currently in the Cookbook web. The color code for this web is this background, so you know where you are.
•If you are not familiar with the TWiki collaboration platform, please visit WelcomeGuest first.

Schematics Cookbook Web Site Tools
• (More options in WebSearch)
• WebChanges: Display recent changes to the Cookbook web
• WebIndex: List all Cookbook topics in alphabetical order. See also the faster WebTopicList
• WebNotify: Subscribe to an e-mail alert sent when something changes in the Cookbook web
• WebStatistics: View access statistics of the Cookbook web
• WebPreferences: Preferences of the Cookbook web (TWikiPreferences has site-wide preferences)

The PLT Scheme is now Racket, a new programming language. The above page is for compatiblity and historical reference only. See the Racket site for up-to-date information. Sphere: Related Content

The Four Elements of Simple Design

I realize that I've never really written this down before, and I say it so frequently in my work as a trainer and mentor, that I think it bears repeating.

I have reduced everything I've ever learned about effective object-oriented design to the four elements of simple design that I first learned from Kent Beck's work. Maybe you can, too.
I define simple design this way. A design is simple to the extent that it:
* Passes its tests
* Minimizes duplication
* Maximizes clarity
* Has fewer elements
Note that I put these properties in priority order. I'm willing to copy-and-paste to get a test passing, but once the test passes, I can usually remove the duplication quickly. I'm willing to extract code into a method and call it foo() in order to get rid of duplicate code, although that name foo() rarely survives more than 15 minutes. Finally, I will gladly introduce interfaces, classes, methods and variables to clarify the intent of a piece of code, although generally speaking once I make things more clear, I can find things to cut.

Some people put “minimize duplication” and “maximize clarity” in a tie for second place. I don’t. My experience has led me to conclude that removing duplication helps more than fixing bad names does. Moreover, removing duplication tends to allow a suitable structure to emerge, whereas bad names highlight an inappropriate distribution of responsibilities. I use this observation as a key element of my demonstration, “Architecture Without Trying”.
Now I should point out that, as a test-driven development (and now also a behavior-driven development) practitioner, I write tests as I draw breath, so I don't really need to emphasize that part.
* Passes its tests
* Minimizes duplication
* Maximizes clarity
* Has fewer elements
I should also point out that I’ve yet to see a codebase with low duplication and high clarity that, nonetheless, had considerably more design elements than it needed, so I don't really need to emphasize that part, either.
* Passes its tests
* Minimizes duplication
* Maximizes clarity
* Has fewer elements
That leaves me with two key elements of simple design: remove duplication and fix bad names. When I remove duplication, I tend to see an appropriate structure emerge, and when I fix bad names, I tend to see responsibilities slide into appropriate parts of the design.
I claim these to be axioms of modular design, with a “parallel postulate” of whether you use objects or not. If you use objects, you get object-oriented design, and if you don’t, you get structured design. (I don’t know how functional design fits into this yet, because I haven’t done enough of it.)
I claim that developing strong skills of detecting duplication, removing duplication, identifying naming problems, and fixing naming problems equates to learning everything ever written about object-oriented design.
Put more simply, if you master removing duplication and fixing bad names, then I claim you master object-oriented design.
Now I wouldn't bother burning your old OOD/OOP books, but I will tell you that if you have an interested buyer, then feel free to sell them. Sphere: Related Content

30 Programming eBooks

Since this post got quite popular I decided to incorporate some of the excellent suggestions posted in the comments, so this list now has more than 30 books in it. [UPDATED: 2010-10-10]

Learning a new programming language always is fun and there are many great books legally available for free online. Here’s a selection of 30 of them:

Lisp/Scheme:
How to Desing Programs
Let Over Lambda
On Lisp
Practical Common Lisp
Programming in Emacs Lisp
Programming Languages. Application and Interpretation (suggested by Alex Ott)
Structure and Interpretation of Computer Programs
Teach Yourself Scheme in Fixnum Days
Visual LISP Developer’s Bible (suggested by skatterbrainz)

Ruby:
Data Structures and Algorithms with Object-Oriented Design Patterns in Ruby
Learn to Program
MacRuby: The Definitive Guide
Mr. Neighborly’s Humble Little Ruby Book (suggested by @tundal45)
Programming Ruby
Read Ruby 1.9
Ruby Best Practices
Ruby on Rails Tutorial Book (suggested by @tundal45)

Javascript:Building iPhone Apps with HTML, CSS, and JavaScript
Eloquent Javascript
jQuery Fundamentals
Mastering Node

Haskell:
Learn You a Haskell for Great Good
Real World Haskell

Erlang:
Concurrent Programming in Erlang
Learn You Some Erlang for Great Good

Python:
Dive into Python
How to Think Like a Computer Scientist – Learning with Python

Smalltalk:
Dynamic Web Development with Seaside
Pharo by Example (based on the next book in this list, suggested by Anonymous)
Squeak by Example

Misc:
Algorithms
The Art of Assembly Language
Beginning Perl
Building Accessible Websites (suggested by Joe Clark)
The C Book
Compiler Construction
Dive Into HTML 5 (suggested by @til)
Higher-Order Perl
The Implementation of Functional Programming Languages (suggested by “Def”)
An Introduction to R
Learn Prolog Now!
Objective-C 2.0 Essentials
Programming Scala

Of course there are many more free programming eBooks, but this list consists of the ones I read or want(ed) to read. This is far from comprehensive and languages that are completely missing are mostly left out on purpose (e.g. PHP, C++, Java). I’m sure somebody else made a list for them somewhere. Sphere: Related Content

Resolving ? Must load Linux kernel before initrd? Error Message in Linux Operating System

Boot loaders such as GRUB (Grand Unified Bootloader), LILO (Linux Loader) etc. enable you to select to boot a particular operating system in multiboot or dual boot systems. After selecting the operating system (for example Linux), the booting process initially starts with the booting of Linux Kernel program. A Linux Kernel program is the central component of a computer operating system. It requires the corresponding drivers to access the device on which the file system is based. To avoid any conflict due to all imaginable drivers in the kernel, it uses initial ramdisk (intrd). The intrd is the temporary file system, which is mostly used for preparations before the real root file system can be mounted. Problems might occur when intrd gets loaded before Linux Kernel program. In such situations, the hard drive volume becomes un-mountable and the data saved in the hard drive becomes inaccessible. In such situations, you need to recover your data from the latest backup. In case, no backup is available or the backup is corrupted, you need to use efficient Linux Data Recovery applications to recover your lost data files.
Consider a practical example, when you attempt to boot Linux operating system, you encounter the below error message:
“Must load Linux kernel before initrd”
The above error message occurs each time you try to boot the Linux operating system on your computer. After the above error message appears, the data saved in the Linux volume becomes inaccessible.

Cause:
The above error message mainly occurs when the intrd gets loaded before the Linux Kernel program.

Resolution:
To resolve the above error and access the data, you need to remove the intrd from your computer. However, if you still encounter an error, then only option left is to access the volume by reinstalling the Linux operating system. A clean reinstall of the operating system will erase all previously stored data in the hard drive. In such scenarios, you need to recover lost data by using effective Linux Data Recovery software. These advanced recovery applications incorporate high-end scanning methods to recover lost data from a logically corrupted hard drive.

Stellar Phoenix Linux Data Recovery serves the purpose of providing reliable and easy Linux Data Recovery. This read only Linux Recovery software supports Ext2, Ext3 and ReiserFS file systems. It gets installed on Windows (Vista, XP, 2003 and 2000) and the affected Linux drive should be connected as slave.

Robin Watson a student of Mass Communication doing research on linux data recovery software. He is also a freelancer for Windows data recovery software. Sphere: Related Content

Unbreakable Enterprise Kernel

Public Yum Server
Last updated: 21 September, 2010

Now Available: Unbreakable Enterprise Kernel

Oracle has released the Unbreakable Enterprise Kernel for x86_64 servers via the Oracle Public Yum Server. Please use the following steps to install the new kernel and any required dependencies.
1. Ensure that your system is running Oracle Linux 5 Update 5 (x86_64) before installing the Unbreakable Enterprise Kernel.
2. Download and install the Oracle Linux 5 repo file to your system.
# cd /etc/yum.repos.d
# wget http://public-yum.oracle.com/public-yum-el5.repo
3. Enable both the [el5_u5_base] and the [ol5_u5_base] repositories in the yum configuration file by changing enable=0 to enable=1 in those sections.
4. To update your system kernel to the Unbreakable Enterprise Kernel, use the following yum command:
# yum install kernel
OR To upgrade all recommended packages associated with the Unbreakable Enterprise Kernel, use the following yum command:
# yum install oracle-linux
5. Reboot your system to run the newly-installed Unbreakable Enterprise Kernel.

Introduction
The Oracle public yum server offers a free and convenient way to install packages from the Oracle Linux and Oracle VM installation media via a yum client.

You can download the full Oracle Linux and Oracle VM installation media via edelivery.oracle.com/linux. Note that errata are not available via this public yum server. To access errata (bug fixes, security fixes and enhancement), you must have a valid support contract to access Unbreakable Linux Network (ULN). For more information, see the FAQ below.

This yum server is offered without support of any kind. If you require support, please consider purchasing Unbreakable Linux support via the online store, or via your sales representative.

Getting Started
Download and Install Oracle Linux
Download and copy the appropriate yum configuration file in place, by running the following commands as root:
Oracle Linux 4, Update 6 or Newer
# cd /etc/yum.repos.d
# mv Oracle-Base.repo Oracle-Base.repo.disabled
# wget http://public-yum.oracle.com/public-yum-el4.repo
Oracle Linux 5
# cd /etc/yum.repos.d
# wget http://public-yum.oracle.com/public-yum-el5.repo
Oracle VM 2
# cd /etc/yum.repos.d
# wget http://public-yum.oracle.com/public-yum-ovm2.repo

Enable the appropriate repository by editing the yum configuration file

Open the yum configuration file in a text editor
Locate the section in the file for the repository you plan to update from, e.g. [el4_u6_base]
Change enabled=0 to enabled=1
Begin using yum, for example:
yum list
yum install firefox
You may be prompted to confirm the import of the Oracle OSS Group GPG key.

Frequently Asked Questions
1) Where are the security updates and other errata ?
2) Where can I learn more about Oracle Linux?
3) Where can I learn more about Unbreakable Linux support?
4) Where can I learn more about Oracle VM?
5) Where can I get help getting this yum repository to work?
6) Where can I learn more about yum?

Where are the security updates and other errata?
A: This yum server only offers the packages already provided on the Oracle Linux and Oracle installation media. To access security updates and other patches or enhancements, you should use Unbreakable Linux Network (ULN). Access to ULN requires a valid Oracle Linux or Oracle VM support contract and Customer Support Identifier (CSI). To obtain a support contract, please contact your sales representative or make your purchase via the Unbreakable Linux Store.
Where can I learn more about Oracle Linux?
A: You can read a summary of features and specifications here. Additional technical information about Oracle Linux is available on OTN's Linux Technology Center.
Where can I learn more about Unbreakable Linux support?
A: You can read more about Oracle Unbreakable Linux Support at oracle.com/linux, For white papers, data sheets, FAQs and other technical information, see the Linux Technology Center.
Where can I learn more about Oracle VM?
A: You can read more about Oracle VM here. For technical information about Oracle VM, see the Oracle VM product page on OTN.
Where can I get help getting this yum repository to work?
A: This yum server is provided for free and without support. You may use the Oracle Technology Network Linux Forum, where other users are ready and willing to help.
Where can I learn more about yum?
A: There are several resources available on the the Web. Here is an overview of basic yum commands

Browse the Repositories
Name Last modified Size
--------------------------------------------------------------------------------
repo/ 19-Sep-2010 20:27 -
public-yum-el4.repo 26-May-2009 11:08 692
public-yum-el5.repo 20-Sep-2010 15:59 2.0K
public-yum-ovm2.repo 22-Apr-2010 11:01 1.3K
RPM-GPG-KEY-oracle-el4 26-Oct-2006 18:50 1.7K
RPM-GPG-KEY-oracle-el5 11-Nov-2007 08:01 1.4K Sphere: Related Content

W3C: Hold off on deploying HTML5 in websites

Despite the hype, the HTML5 specification isn't yet ready due to interoperability issues, a W3C official says
By Paul Krill | InfoWorld

HTML5, which updates the HTML specification to accommodate modern Web applications, has gained a lot of adherents in vendors like Microsoft, Google, and Apple. But the specification is plain not ready yet for deployment to websites, an official with the World Wide Web Consortium (W3C), which oversees HTML5, stressed this week.

"The problem we're facing right now is there is already a lot of excitement for HTML5, but it's a little too early to deploy it because we're running into interoperability issues," including differences between video on devices, said the official, Philippe Le Hegaret, W3C interaction domain leader. He is responsible for specifications like HTML and SVG (Scalable Vector Graphics).

[ See InfoWorld's reports on how to use HTML5 on your website today, whether HTML5 will kill off Flash and Silverlight and how HTML5 will change the Web. | Keep up with app dev issues and trends with InfoWorld's Fatal Exception blog and Developer World newsletter. ]

"I don't think it's ready for production yet," especially since W3C still will make some changes on APIs, said Le Hegaret. "The real problem is can we make [HTML5] work across browsers and at the moment, that is not the case."

His advice on HTML5 was endorsed by industry analyst Al Hilwa of IDC.

"HTML 5 is at various stages of implementation right now through the Web browsers. If you look at the various browsers, most of the aggressive implementations are in the beta versions," Hilwa said. "IE9 (Internet Explorer 9), for example, is not expected to go production until close to mid-next year. That is the point when most enterprises will begin to consider adopting this new generation of browsers."

A vendor with an interest in the specification said some parts of HTML5 are ready and some are not.

"The point of HTML5 is this has been an ongoing effort for a while now and many parts of HTML5 are already in the wild," such as Canvas 2D capabilities and WebSockets, for communicating between browsers, said John Fallows, CTO of Kaazing, which makes a WebSockets gateway.

Le Hegaret acknowledged HTML5 is viewed as a "game changer." Companies now can deploy HTML5 in their applications or in intranets where a rendering engine can be controlled, said Le Hegaret. But it is a different story on the "open Web," where interoperability is an issue, he added.

"What's happening is the industry is realizing that HTML5 is going to be real," said Le Hegaret.

The HTML5 specification itself features support for video and Canvas 2D. But other technologies such as CSS (Cascading Style Sheets) and MathML are considered part of the "open Web platform" along with HTML5, even if they are not covered by the actual specification, Le Hegaret said. SVG is referenced by the HTML5 specification.

Apple has positioned HTML5 as a replacement for Adobe's Flash rich Internet technology. But Flash and similar technologies, such as Microsoft Silverlight, still have a place, Le Hegaret said.
"We're not going to retire Flash anytime soon," Le Hegaret said. It will take years before all Web clients support HTML5, he said. He cited Microsoft's IE6 browser as an example of popular client not supporting the standard. "IE6 is still being used on the Web today, and it is 10 years old."

Over time, however, HTML5 will become the standard for websites, he said. "You will see less and less websites using Flash," said Le Hegaret.

Meanwhile, HTML5 is headed toward final approval in two to three years. HTML5 development was begun in 2004 by the Web Hypertext Application Technology Working Group.

"We basically want to be feature-complete by mid-2011," Le Hegaret said. Once the specification reaches that stage, W3C will issue a last call for comments. The next stage would be the candidate recommendation stage and then a recommendation stage. "And then we're done," Le Hegaret said.

Le Hegaret also acknowledged some other shortcomings in HTML5. For example, HTML5 lacks a video codec, and Le Hegaret does not expect to have one in the upcoming specification. "It's a patent issue," he said. The MPEG-4 codec, for example, is covered by patents, Le Hegaret said.

Digital rights management also is not supported in HTML5, he said. This means some video producers will not deploy their videos in HTML5 without this type of protection, he said.

HTML5 is an open standard, presenting a problem for DRM. "If we are going to develop a solution for DRM which is open, it would be broken by a hacker within two days," he said. "There is no point of us doing that."

There is a possibility for DRM in HTML5 at some point, however, but it is not in the plan at the moment, said Le Hegaret.

HTML5 also lacks authoring tools at the moment, he said. Adobe does offer one that works with its Creative Suite package, however, said Le Hegaret.

This article, "W3C: Hold off on HTML5 in websites," was originally published at InfoWorld.com. Follow the latest developments in business technology news and get a digest of the key stories each day in the InfoWorld Daily newsletter.

Read more about software development in InfoWorld's Developer World Channel. Sphere: Related Content

JavaScript Programming Patterns

JavaScript is meant to be used to add behaviour to a website, might it be for form validation or for more complex operations like drag & drop functionality or performing asynchronous requests to the webserver (aka Ajax). During the past few years, JavaScript libraries became increasingly popular. One of the reasons is definitely that websites are getting more and more complex and reinventing the wheel each time is not acceptable if you are working on a tight schedule. But letting aside libraries and focusing on the “bare” syntax of JavaScript, it is very valuable to know what kind of options you have in terms of programming patterns when writing JavaScript.

In this article I am trying to present some of the techniques out there that I have discovered. The patterns I would like to mention are the following:
* The Old-School Way
* Singleton
* Module Pattern
* Revealing Module Pattern
* Custom Objects
* Lazy Function Definition
The way I decided to present and compare these different patterns is by solving the same given task with every pattern. The task is: You have three links on a page and when clicking the links, the background color of that link should change to a preconfigured value. The markup looks like this:
ul
li a href="http://news.bbc.co.uk/">News on BBC website /a /li
li a href="http://nytimes.com/">Frontpage of The New York Times /a /li
li a href="http://www.guardian.co.uk/">Guardian Unlimited /a /li
/ul
To complete the task given, you essentially would need to complete the following steps:
* Define the background colors in some kind of configuration variable
* Get all the anchors on the page and store them in a data structure (array)
* Loop through that array and attach an onclick event to them, pointing to a function that changes the background color
* If the link gets clicked that function gets executed and the background color of the link clicked gets changed

The Old-School Way
I would like to start off with demonstrating how this task would have been solved in the late 90′s, early 2000. At that time, JavaScript was purely used to do sequential programming, defining one function after the other. Nobody worried about namespace. Nobody worried about re-usability of code. Nobody worried in general, cause each script kiddie was paid a huge amount of money. They couldn’t be bothered with such things. To make everything at least a bit more neat, I decided to use function definitions, even if you could write some of that code straight into the bode of the page (to make things even worse). So you could have 2 functions:
anchorChange1: collects the links and attaches the event
changeColor1: executes the actual swap of the background color
Without further ado, your final code might look like this:
function changeColor1(linkObj, newColor) {
linkObj.style.backgroundColor = newColor;
}

function anchorChange1() {
// set configuration
var config = {
colors: [ "#F63", "#CC0", "#CFF" ]
};

// get all links on page
var anchors = document.getElementsByTagName("a");
var size = anchors.length;

// loop through anchors and attach events
for (var i = 0; i < size; i++) {
anchors[i].color = config.colors[i];

anchors[i].onclick = function () {
changeColor1(this, this.color);
return false;
};
}
}
In a JavaScript block on the page – after the anchor and preferably close to the closing body-tag – you then only need to call the main function:

Please proceed to the working example. It works fine, although it has the problem of cluttering up the global namespace. This means, in a much more complex situation with several developers working on the same project, you have a big problem if someone comes up with something like this:
function changeColor1() {
alert("oh noes, my code got overwritten!");
}
If that gets defined after your own definition of changeColor1, your code will get overwritten by that second definition of the function with the same name. As stated in the introduction, website projects are far more complex theses day (with possibly several frontend developers working on it) than they were 5 to 10 years ago. So there is a potential danger that someone overwrites somebody else’s code and tracking down that problem can become a pure nightmare. So these days, I believe this technique should be avoided altogether.

Singleton
The second solution is dealing with the creation of a singleton, which means creating an object and assigning values (e.g. functions) to its properties. This object is immediately available for use and can be created using the following syntax:
var testObject = {};
For a start, I created an empty singleton:
anchorChange2 = {};
I decided to create 3 different properties for this object:
* config: holds the different background colors
* alterColor: method which does the actual color change
* init: attaches the alterColor function to the link element
The config property holds the new background colors:
config: {
colors: [ "#F63", "#CC0", "#CFF" ]
}

alterColor changes the background color to the new color:
alterColor: function (linkObj, newColor) {
linkObj.style.backgroundColor = newColor;
}

init is responsible for linking the onclick event to the alterColor method:
init: function () {
var self = this; // assign reference to current object to "self"

var anchors = document.getElementsByTagName("a");
var size = anchors.length;

for (var i = 0; i < size; i++) {
anchors[i].color = self.config.colors[i];

anchors[i].onclick = function () {
self.alterColor(this, this.color); // this is bound to the anchor object
return false;
};
}
}

The final singleton looks like this:
// singleton syntax
// creates a class and immediately instantiates an object
var anchorChange2 = {
config: {
colors: [ "#F63", "#CC0", "#CFF" ]
},

// does the actual change of the background color
alterColor: function (linkObj, newColor) {
linkObj.style.backgroundColor = newColor;
},

init: function () {
var self = this; // assign reference to current object to "self"

// get all links on the page
var anchors = document.getElementsByTagName("a");
var size = anchors.length;

for (var i = 0; i < size; i++) {
anchors[i].color = self.config.colors[i];

anchors[i].onclick = function () {
self.alterColor(this, this.color); // this is bound to the anchor object
return false;
};
}
}
};
Please proceed to the working example, annotated with some comments.

Module Pattern
Taking the singleton pattern one step further leads us to what Douglas Crockford calls the “module pattern”. The idea is to have an encapsulated module, that cannot conflict with any other modules you or someone else has created. You can create public and private methods within that module.

First, lets create a function that gets executed immediately (which is caused by parens after the closing curly bracket):
anchorChange3 = function () {}();
As stated before, with this programming pattern, you can have public and private methods. Public methods can be accessed from outside, private methods only from within the object. I decided to have a private variable config, a private method alterColor, which does the actual color change, and 2 public methods, which are bound to the object itself. For this to happen, you return an object with the respective properties:
return {
// public method
// can be accessed from outside
changeColor: function (linkObj, newColor) {
alterColor(linkObj, newColor);
},

// public method
init: function () {
var self = this; // assign reference to current object to "self"

// get all links on the page
var anchors = document.getElementsByTagName("a");
var size = anchors.length;

for (var i = 0; i < size; i++) {
anchors[i].color = config.colors[i];

anchors[i].onclick = function () {
self.changeColor(this, this.color); // this is bound to the anchor object
return false;
};
}
}
};

The alterColor function, as well as the config variable, live within the parent function anchorChange3, but outside the returned object:
var config = {
colors: [ "#F63", "#CC0", "#CFF" ]
}

function alterColor(linkObj, color) {
linkObj.style.backgroundColor = color;
}
As alterColor is a private method, it cannot be accessed from outside. To be able to execute that function you either need to put it in the object (which will basically lead you to using the singleton pattern again), or create another property within the returned object that calls the method. I have done the latter by creating changeColor which then calls alterColor.

The final code for this pattern looks like this:
anchorChange3 = function () {

// private property
var config = {
colors: [ "#F63", "#CC0", "#CFF" ]
}

// this is a private method
// can be accessed within anchorChange3
// cannot be accessed from outside
function alterColor(linkObj, color) {
linkObj.style.backgroundColor = color;
}

return {
// public method
// can be accessed from outside
changeColor: function (linkObj, newColor) {
// calls private function to change color
alterColor(linkObj, newColor);
},

// public method
// can be accessed from outside
init: function () {
var self = this; // assign reference to current object to "self"

// get all links on the page
var anchors = document.getElementsByTagName("a");
var size = anchors.length;

for (var i = 0; i < size; i++) {
anchors[i].color = config.colors[i];

anchors[i].onclick = function () {
self.changeColor(this, this.color);//this is bound to the anchor
object
return false;
};
}
}
};
As with the general singleton example above, in the body of the HTML document you would then need to call the init method:

Please proceed to the working example. The source code is, again, annotated with comments to hopefully make clear what is happening.

Revealing Module Pattern
Based on some investigations on how he could overcome some things he did not like about the module pattern, Christian came up with something that he calls Revealing Module Pattern. As the name indicates, it is related to the Module Pattern, but might be a bit more structured and easier to understand, especially when it comes to handing over code to other developers in your team.

First, it starts again with a basic function, which gets defined and called immediately:
var anchorChange4 = function () {}();
After that, all the properties and methods get defined, without paying attention to whether they are actually private or public:
// this will be a private property
var config = {
colors: [ "#F63", "#CC0", "#CFF" ]
}

// this will be a public method
var init = function () {
var self = this; // assign reference to current object to "self"

// get all links on the page
var anchors = document.getElementsByTagName("a");
var size = anchors.length;

for (var i = 0; i < size; i++) {
anchors[i].color = config.colors[i];

anchors[i].onclick = function () {
self.changeColor(this, this.color); // this is bound to the anchor object
return false;
};
}
}

// this will be a public method
var changeColor = function (linkObj, newColor) {
linkObj.style.backgroundColor = newColor;
}
Now we are getting to the interesting part. Switching back to the original Module Pattern, I am sure you have noticed that it ends with the return statement which holds all the public properties and methods. In the Revealing Module Pattern, you only put references to those properties and methods in there that you want to have publicly available:
return {
// declare which properties and methods are supposed to be public
init: init,
changeColor: changeColor
}
The only two properties needed to be publicly available are init (which does all the preparation work) and changeColor (which gets called when an anchor gets clicked). Looking at the code makes it clear right away which properties and methods are publicly available. The final code looks like this:
// revealing module pattern
var anchorChange4 = function () {

// this will be a private property
var config = {
colors: [ "#F63", "#CC0", "#CFF" ]
}

// this will be a public method
var init = function () {
var self = this; // assign reference to current object to "self"

// get all links on the page
var anchors = document.getElementsByTagName("a");
var size = anchors.length;

for (var i = 0; i < size; i++) {
anchors[i].color = config.colors[i];

anchors[i].onclick = function () {
self.changeColor(this, this.color); // this is bound to the anchor object
return false;
};
}
}

// this will be a public method
var changeColor = function (linkObj, newColor) {
linkObj.style.backgroundColor = newColor;
}

return {
// declare which properties and methods are supposed to be public
init: init,
changeColor: changeColor
}
}();
As with all the other patterns, you need to call the respective function in a script block in your page:

And again, the working example for this pattern.

Custom Objects
The method of creating a new object of a class (instantiating it) is common in all object-oriented languages. But JavaScript is object-based rather than object-oriented. In JavaScript, you just need to call the constructor function of your (custom) object with respective parameters to create an object. You do not have any classes or subclasses as e.g. in Java.

First, we would need to create a constructor function for our object:
var anchorChanger = function () {};
We leave the constructor empty for now (which is totally fine), but later on we will add a call to the init method of that object.

Using prototype, we can now add additional properties to the object “blueprint” so that these items are available for every instance of that object right from the start. I ended up with having 3 properties, namely: config, changeColor and init.
anchorChanger.prototype.config = {
colors: [ "#F63", "#CC0", "#CFF" ]
}

anchorChanger.prototype.changeColor = function (linkObj, newColor) {
linkObj.style.backgroundColor = newColor;
};

anchorChanger.prototype.init = function () {
var self = this;

var anchors = document.getElementsByTagName("a");
var size = anchors.length;

for (var i = 0; i < size; i++) {
anchors[i].color = self.config.colors[i];

anchors[i].onclick = function () {
self.changeColor(this, this.color);
return false;
};
}
};

Module Pattern
Taking the singleton pattern one step further leads us to what Douglas Crockford calls the “module pattern”. The idea is to have an encapsulated module, that cannot conflict with any other modules you or someone else has created. You can create public and private methods within that module.

First, lets create a function that gets executed immediately (which is caused by parens after the closing curly bracket):
anchorChange3 = function () {}();
As stated before, with this programming pattern, you can have public and private methods. Public methods can be accessed from outside, private methods only from within the object. I decided to have a private variable config, a private method alterColor, which does the actual color change, and 2 public methods, which are bound to the object itself. For this to happen, you return an object with the respective properties:
return {
// public method
// can be accessed from outside
changeColor: function (linkObj, newColor) {
alterColor(linkObj, newColor);
},

// public method
init: function () {
var self = this; // assign reference to current object to "self"

// get all links on the page
var anchors = document.getElementsByTagName("a");
var size = anchors.length;

for (var i = 0; i < size; i++) {
anchors[i].color = config.colors[i];

anchors[i].onclick = function () {
self.changeColor(this, this.color); // this is bound to the anchor object
return false;
};
}
}
};
The alterColor function, as well as the config variable, live within the parent function anchorChange3, but outside the returned object:
var config = {
colors: [ "#F63", "#CC0", "#CFF" ]
}

function alterColor(linkObj, color) {
linkObj.style.backgroundColor = color;
}
As alterColor is a private method, it cannot be accessed from outside. To be able to execute that function you either need to put it in the object (which will basically lead you to using the singleton pattern again), or create another property within the returned object that calls the method. I have done the latter by creating changeColor which then calls alterColor.

The final code for this pattern looks like this:
var anchorChange3 = function () {

// private property
var config = {
colors: [ "#F63", "#CC0", "#CFF" ]
}

// this is a private method
// can be accessed within anchorChange3
// cannot be accessed from outside
function alterColor(linkObj, color) {
linkObj.style.backgroundColor = color;
}

return {
// public method
// can be accessed from outside
changeColor: function (linkObj, newColor) {
// calls private function to change color
alterColor(linkObj, newColor);
},

// public method
// can be accessed from outside
init: function () {
var self = this; // assign reference to current object to "self"

// get all links on the page
var anchors = document.getElementsByTagName("a");
var size = anchors.length;

for (var i = 0; i < size; i++) {
anchors[i].color = config.colors[i];

anchors[i].onclick = function () {
self.changeColor(this, this.color); // this is bound to the anchor object
return false;
};
}
}
};
}();
As with the general singleton example above, in the body of the HTML document you would then need to call the init method:

Please proceed to the working example. The source code is, again, annotated with comments to hopefully make clear what is happening.

Revealing Module Pattern
Based on some investigations on how he could overcome some things he did not like about the module pattern, Christian came up with something that he calls Revealing Module Pattern. As the name indicates, it is related to the Module Pattern, but might be a bit more structured and easier to understand, especially when it comes to handing over code to other developers in your team.

First, it starts again with a basic function, which gets defined and called immediately:
var anchorChange4 = function () {}();
After that, all the properties and methods get defined, without paying attention to whether they are actually private or public:
// this will be a private property
var config = {
colors: [ "#F63", "#CC0", "#CFF" ]
}

// this will be a public method
var init = function () {
var self = this; // assign reference to current object to "self"

// get all links on the page
var anchors = document.getElementsByTagName("a");
var size = anchors.length;

for (var i = 0; i < size; i++) {
anchors[i].color = config.colors[i];

anchors[i].onclick = function () {
self.changeColor(this, this.color); // this is bound to the anchor object
return false;
};
}
}

// this will be a public method
var changeColor = function (linkObj, newColor) {
linkObj.style.backgroundColor = newColor;
}
Now we are getting to the interesting part. Switching back to the original Module Pattern, I am sure you have noticed that it ends with the return statement which holds all the public properties and methods. In the Revealing Module Pattern, you only put references to those properties and methods in there that you want to have publicly available:
return {
// declare which properties and methods are supposed to be public
init: init,
changeColor: changeColor
}
The only two properties needed to be publicly available are init (which does all the preparation work) and changeColor (which gets called when an anchor gets clicked). Looking at the code makes it clear right away which properties and methods are publicly available. The final code looks like this:
// revealing module pattern
var anchorChange4 = function () {

// this will be a private property
var config = {
colors: [ "#F63", "#CC0", "#CFF" ]
}

// this will be a public method
var init = function () {
var self = this; // assign reference to current object to "self"

// get all links on the page
var anchors = document.getElementsByTagName("a");
var size = anchors.length;

for (var i = 0; i < size; i++) {
anchors[i].color = config.colors[i];

anchors[i].onclick = function () {
self.changeColor(this, this.color); // this is bound to the anchor object
return false;
};
}
}

// this will be a public method
var changeColor = function (linkObj, newColor) {
linkObj.style.backgroundColor = newColor;
}

return {
// declare which properties and methods are supposed to be public
init: init,
changeColor: changeColor
}
}();
As with all the other patterns, you need to call the respective function in a script block in your page:

And again, the working example for this pattern.

Custom Objects
The method of creating a new object of a class (instantiating it) is common in all object-oriented languages. But JavaScript is object-based rather than object-oriented. In JavaScript, you just need to call the constructor function of your (custom) object with respective parameters to create an object. You do not have any classes or subclasses as e.g. in Java.

First, we would need to create a constructor function for our object:
var anchorChanger = function () {};
We leave the constructor empty for now (which is totally fine), but later on we will add a call to the init method of that object.

Using prototype, we can now add additional properties to the object “blueprint” so that these items are available for every instance of that object right from the start. I ended up with having 3 properties, namely: config, changeColor and init.
anchorChanger.prototype.config = {
colors: [ "#F63", "#CC0", "#CFF" ]
}

anchorChanger.prototype.changeColor = function (linkObj, newColor) {
linkObj.style.backgroundColor = newColor;
};

anchorChanger.prototype.init = function () {
var self = this;

var anchors = document.getElementsByTagName("a");
var size = anchors.length;

for (var i = 0; i < size; i++) {
anchors[i].color = self.config.colors[i];

anchors[i].onclick = function () {
self.changeColor(this, this.color);
return false;
};
}
};
As pointed out by Mike West, using prototype is much more efficient than creating these methods “on the fly” every time a new object gets created. The final custom object looks like this:
// custom object constructor
var anchorChanger = function () {
this.init();
};

anchorChanger.prototype.config = {
colors: [ "#F63", "#CC0", "#CFF" ]
}

anchorChanger.prototype.changeColor = function (linkObj, newColor) {
linkObj.style.backgroundColor = newColor;
};

anchorChanger.prototype.init = function () {
var self = this;

// get all links on the page
var anchors = document.getElementsByTagName("a");
var size = anchors.length;

for (var i = 0; i < size; i++) {
anchors[i].color = self.config.colors[i];

anchors[i].onclick = function () {
self.changeColor(this, this.color);
return false;
};
}
};
In the body of the document, you just need to create a new instance of anchorChanger:

As with the examples before, you can check out a live demo together with comments.

Lazy Function Definition
Peter Michaux came up with a pattern that he calls Lazy Function Definition. This pattern is particularly useful when you need to do computations on the page once and then reuse the output multiple times. With this pattern, you ensure that stuff that should be done once, is indeed only done once. The example that Peter is giving deals with putting together a scrolling function based on different browser environments. Based on the browser model, the scrolling function is put together differently when the function gets called for the first time.

For my task, this pattern does not provide a real advantage, cause there is just no heavy or complex computation needed. But how does it work in general? You start with your basic function definition:
var anchorChange5 = function () {};
The I added the properties, much like I did with the other patterns above:
// define configuration
var config = {
colors: [ "#F63", "#CC0", "#CFF" ]
};

// get all links
var anchors = document.getElementsByTagName("a");
var size = anchors.length;

// loop through anchors and attach events
for (var i = 0; i < size; i++) {
anchors[i].color = config.colors[i];

anchors[i].onclick = function () {
anchorChange5().changeColor(this, this.color);
return false;
};
}
All the above should only be done once and there is no need to include these properties in subsequent calls to that function. To put the Lazy Function Definition in the game, you need to redeclare your function:
// redefine function so that it only holds the changeColor function
anchorChange5 = function () {
return {
changeColor: function (linkObj, newColor) {
linkObj.style.backgroundColor = newColor;
}
};
};
So the final code for the Lazy Function Definition Pattern looks like this:
// lazy function definition
var anchorChange5 = function () {
// define configuration
var config = {
colors: [ "#F63", "#CC0", "#CFF" ]
};

// get all links
var anchors = document.getElementsByTagName("a");
var size = anchors.length;

// loop through anchors and attach events
for (var i = 0; i < size; i++) {
anchors[i].color = config.colors[i];

anchors[i].onclick = function () {
anchorChange5().changeColor(this, this.color);
return false;
};
}

// redefine function so that it only holds the changeColor function
anchorChange5 = function () {
return {
changeColor: function (linkObj, newColor) {
linkObj.style.backgroundColor = newColor;
}
};
};
};
What happens is:
1. anchorChange5 gets called and defines the config variable and collects all the anchors on the page
2. An onclick event gets attached to every anchor, with a call to the changeColor method of the redeclared anchorChange5 function
3. After that, anchorChange5 gets redeclared and only holds the changeColor method, which can be accessed as a public method

And again, in the body of the page, you call the function:

There is, again, a working example with comments. As stated above, this pattern is not that handy here, but consider a situation when there is some heavy and complex computing involved. You certainly do not want to do that each time the function gets called. Peter calls this kind of function definition a “promise”, which means the outer declaration can be viewed as some kind of promise that later on this function will get redeclared to provide something more useful.

Appendix: Copy & Paste Example
The following code is an template/example you can copy & paste into your favourite editor and build up your module/feature from there. It is based on the Revealing Module Pattern and assumes you are using the Yahoo! User Interface Library (YUI). To get further filepaths of components to include for your module, visit Serving YUI Files from Yahoo! Servers.


Conclusion
As stated above, these are my assumptions on how this particularly simple task can be accomplished. I am sure that there are some other ways of approaching this problem, but my point in going through these exercises was to teach myself how these different methods work in general.

There is no general solution on how such problems should be approached. For a task like this, I believe that the singleton pattern is the most convenient way of doing it. Mostly because less lines of code are required. But for other, more complex problems, using the module pattern or creating custom objects or the lazy function definition might be more appropriate.

Thanks for reading and checking out the examples. I would be very happy if you could provide me with feedback.

Further reading
A JavaScript Module Pattern: explaining how all this is applied at Yahoo!
Christian Heilmann tells you how to Show love to the Module Pattern
Lazy Function Definition Pattern by Peter Michaux
Christian again, describing what he calls Revealing Module Pattern
Richard Cornford on JavaScript Closures
Douglas Crockford on Classical Inheritance in JavaScript
Kevin Lindsey’s approach to simulating object-oriented programming in JavaScript
Harry Fuecks from SitePoint on JavaScript inheritance Sphere: Related Content

How Good C# Habits can Encourage Bad JavaScript Habits: Part 1

This is the first post in a multi-part series covering common mistakes C# developers tend to make when they first start writing JavaScript.

Introduction
Many people come to jQuery and believe that their knowledge of a previous classical language (C#, Java, etc) will help them be successful at client-side scripting. You can use your classical language skills to accomplish a large amount of functionality with jQuery. However, the more client-side code you write you will find yourself uncovering strange bugs because you didn’t take adequate time to learn JavaScript properly.
“…it turns out that if you have absolutely no idea what you’re doing in the language you can still generally make things work.” –Douglas Crockford, Yahoo!’s JavaScript Architect, Douglas on JavaScript -- Chapter 2: And Then There Was JavaScript

This article is targeted for developers that use jQuery but haven’t invested the time necessary to learn JavaScript. The intent is to help you avoid some common mistakes when moving from a classical language (Java, C#, etc) to JavaScript.

jQuery is a library that is written in JavaScript. It is important to remember that you will always be writing in JavaScript when using jQuery. It is inevitable that you will run into native JavaScript concepts that are foreign to the classical language proficient developer. Taking the time now to be proficient in JavaScript will increase your client-side code quality, efficiency, and decrease code maintenance.

Bad Practices
1. Having Variables & Functions in Global Scope
A best practice in C# is to limit the use of global variables. This doesn’t necessarily translate into a bad practice in JavaScript, but most C# developers are not aware of how easily it is to pollute the global namespace with needless variables and functions.

One way you can pollute the global namespace is to not declare your variables. In JavaScript, if you don’t declare your variables then they become globally available to the rest of the program, which is probably not what you wanted and generally a bad idea.

Coming from a C# background, you are most likely used to the concept of namespacing your classes so they won’t clash with other libraries. In the same way you should be mindful to not declare variables or functions in the global namespace to prevent clashing with other libraries, browser extensions, and also your own code.

Bad Practice
The following code shows some bad examples of how to declare variables and functions.
var iAmGlobal = "Keep these to a minimum";

iAmGlobalToo = "Bad";

function oldSchoolWay() {
//Placed in global scope when executed
iAmGlobalNooo = "Really Bad";

console.log( "Bad oldSchoolWay Function" );
}

//Bad way to prevent namespace clashing
function namespace_oldSchoolWay() {
console.log( "Worse oldSchoolWay Function" );
}

//Functions
window.oldSchoolWay();
window.namespace_oldSchoolWay();

//Global variables are available off window object
console.log( window.iAmGlobal );
console.log( window.iAmGlobalToo );
console.log( window.iAmGlobalNooo );
You can execute and modify the above code from jsFiddle.

In the above code snippet you’ll see that the iAmGlobal, iAmGlobalToo, and iAmGlobalNooo are all global variables. You would expect iAmGlobal and probably iAmGlobalToo to be global variables, but the variable inside the oldSchoolWay function is also global because it was never declared! The best way to stay out of this trouble is to be disciplined and declare all of your variables and not let JavaScript do it for you.

Klaus Komenda actually refers to the function statement as the Old School Way of function declaration. I’ve even seen C# developers trying to prefix their function names (as shown above by namespace_oldSchoolWay) to minimize collisions with other libraries, but you should not do this. That technique still clutters the global namespace.

There are many options to fix this problem, but the simplest is to create a namespace object and then declare all your functions and properties within it. See the following code snippet for a slightly better approach.

Object Literal (All Public)
An Object Literal is a convenient way to create new objects. The syntax looks very similar to what you might expect to see in JSON (JavaScript Object Notation), but they are actually quite different. For more information about this you can check out an in-depth discussion on it by Ben Alman entitled There's no such thing as a "JSON Object".

When you create an Object Literal you can provide properties and methods and they can refer to each other. You can also add additional methods and properties to the object after it has been defined. All the properties and methods that you declare in the Object Literal are publicly accessible to the rest of your JavaScript code.
//Object Literal declaring properties and methods
var skillet = {
//public property
ingredient: "Bacon Strips",

//public method
fry: function() {
console.log( "Frying " + this.ingredient );
}
};
console.log( skillet.ingredient ); //Bacon Strips
skillet.fry(); //Frying Bacon Strips

//Adding a public property to an Object Literal
skillet.quantity = "12";
console.log( skillet.quantity ); //12

//Adding a public method to an Object Literal
skillet.toString = function() {
console.log( this.quantity + " " +
this.ingredient );
};
skillet.toString(); //12 Bacon Strips​
You can execute and modify the above code from jsFiddle.

The above code declares a skillet variable and sets it to an Object Literal with one property (ingredient) and one method (fry) that are both publicly accessible off of the object. You can also add additional public methods and properties to the object after the initial declaration as shown above when adding the quantity property and the toString method. The toString method is able to access the properties of the skillet object since all of it’s parts are public.

Pros
•Cleans up the global namespace by adding a namespace to your properties and methods
•You can add functionality to the object literal at a later point
•All the properties and methods are public

Cons
•Uses the Object Literal syntax to define your properties and methods that some may find cumbersome
•There isn’t the ability to have private properties or methods

Self-Executing Anonymous Function: Part 1 (All Private)
Another common technique that you can use to protect the global namespace is to use a Self-Executing Anonymous Function. This is just a fancy term to refer to a function with no name that is immediately executed after it’s defined. The value of this technique is that you can create a wrapper around your code that protects it from the global namespace. By using the most simple version of the Self-Executing Anonymous Function you can create code that is exclusively private.
//Self-Executing Anonymous Function: Part 1 (All Private)
(function() {
//private variable
var ingredient = "Bacon Strips";

//private function
function fry() {
console.log( "Frying " + ingredient );
}

fry();
}());

//Variables not accessible
console.log( window.ingredient ); //Undefined

//Functions not accessible
try {
window.fry(); //Throws Exception
} catch( e ) {
//Object [object DOMWindow] has no method 'fry'
console.log( e.message );
}

//Can't add additional functionality
You can execute and modify the above code from jsFiddle.

The above code snippet wraps the ingredient variable and fry function with a Self-Executing Anonymous Function and right before the function ends it executes the fry method. After the Self-Executing Anonymous Function finishes executing there is no way to run the function again or reference any of the internals of the wrapped code.

Pros
•Hides all your implementation from external code
•The function runs once and only once
•The code inside doesn’t use the Object Literal notation

Cons
•All information is hidden, which may not be what you want
•Slightly more complicated technique, but not really

Revealing Module Pattern (Public & Private)
The Revealing Module Pattern actually uses the concept of the Self-Executing Anonymous Function as well, but in this case we save the result into a variable. This pattern introduces the concept of a Closure. A closure is a way to keep variables alive after a function has returned. The Mozilla Developer Network has a great page explaining closures. In it they provide a core definition:
“A closure is a special kind of object that combines two things: a function, and the environment in which that function was created. The environment consists of any local variables that were in-scope at the time that the closure was created.”

In the following example we will declare private properties and methods as well as public properties and methods.
//Revealing Module Pattern (Public & Private)
var skillet = (function() {
var pub = {},
//Private property
amountOfGrease = "1 Cup";

//Public property
pub.ingredient = "Bacon Strips";

//Public method
pub.fry = function() {
console.log( "Frying " + pub.ingredient );
};

//Private method
function privateWay() {
//Do something...
}

//Return just the public parts
return pub;
}());

//Public Properties
console.log( skillet.ingredient ); //Bacon Strips

//Public Methods
skillet.fry();

//Adding a public property to a Module
skillet.quantity = 12;
console.log( skillet.quantity ); //12

//Adding a public method to a Module
skillet.toString = function() {
console.log( skillet.quantity + " " +
skillet.ingredient + " & " +
amountOfGrease + " of Grease" );
};

try {
//Would have been successful,
//but can't access private variable
skillet.toString();
} catch( e ) {
console.log( e.message ); //amountOfGrease is not defined
}
You can execute and modify the above code from jsFiddle.

Inside of the Revealing Module Pattern we declared a pub object that will keep all the public properties and methods that you want to be exposed. At the end of the Module the pub object is returned, which is what causes the them to be public outside of the Self-Executing Anonymous Function. All the parts that were not added to the pub object remain private to the outside world; however, the public methods that were exposed have access to the private parts because of the Closure that was created.

Pros
•Allows for public and private properties and methods
•The Technique is Easy to understand
•The code inside doesn’t use the Object Literal notation

Cons
•Doesn’t allow for a way to add private properties to be used in new public methods

Self-Executing Anonymous Function: Part 2 (Public & Private)
We looked at the Self-Executing Anonymous Function earlier as a pattern you could use to keep all your code private. As it turns out, you can actually modify the pattern somewhat so that you can achieve the same benefits of the Revealing Module Pattern. Not only can we achieve public and private properties and methods, but we can also provide an easy way to extend the namespace while keeping the content protected from the global namespace. In addition, the following pattern can protect the $ from conflicting with other JavaScript libraries and also protect undefined from being redefined.

Take a look at the following example, and we will walk through the code explaining the key changes to the pattern.
//Self-Executing Anonymous Func: Part 2 (Public & Private)
(function( skillet, $, undefined ) {
//Private Property
var isHot = true;

//Public Property
skillet.ingredient = "Bacon Strips";

//Public Method
skillet.fry = function() {
var oliveOil;

addItem( "\t\n Butter \n\t" );
addItem( oliveOil );
console.log( "Frying " + skillet.ingredient );
};

//Private Method
function addItem( item ) {
if ( item !== undefined ) {
console.log( "Adding " + $.trim(item) );
}
}
}( window.skillet = window.skillet || {}, jQuery ));

//Public Properties
console.log( skillet.ingredient ); //Bacon Strips

//Public Methods
skillet.fry(); //Adding Butter & Fraying Bacon Strips

//Adding a Public Property
skillet.quantity = "12";
console.log( skillet.quantity ); //12

//Adding New Functionality to the Skillet
(function( skillet, $, undefined ) {
//Private Property
var amountOfGrease = "1 Cup";

//Public Method
skillet.toString = function() {
console.log( skillet.quantity + " " +
skillet.ingredient + " & " +
amountOfGrease + " of Grease" );
console.log( isHot ? "Hot" : "Cold" );
};
}( window.skillet = window.skillet || {}, jQuery ));

try {
//12 Bacon Strips & 1 Cup of Grease
skillet.toString(); //Throws Exception
} catch( e ) {
console.log( e.message ); //isHot is not defined
}
You can execute and modify the above code from jsFiddle.

First, since we have a Self-Executing Anonymous Function, we can actually provide some parameters to pass to it when it executes. In this case we are passing 2 arguments to the anonymous function.

The first argument looks quite strange. What is window.skillet = window.skillet || {} doing? The code checks to see if skillet exists in the global namespace (window). If it does not exist, then window.skillet is assigned an empty object literal. Using this approach we can build a library across JavaScript files. If another script uses the same technique, then it will pass in the existing instance and append logic to it. Inside the Anonymous Function, if we want something to be public, then we append it to the skillet object. Any other properties or methods will be considered private.

The second argument passed in jQuery. The benefit of this is that the named parameter is referenced as $, which allows us to refer to jQuery as $ within the Anonymous Function without having to worry that it will conflict with the $ declared in other JavaScript libraries. This is a common practice that you will most likely run across when looking at well written jQuery code.

You might notice a 3rd parameter to the Anonymous Function called undefined. Why did we add that parameter and why didn’t we pass an argument to it? In JavaScript, you can unfortunately redefine what undefined means. Imagine that some code somewhere deep in one of your 3rd party libraries redefines undefined to something strange like true. If anywhere in your code you test against undefined, then you code will most likely not behave like you intended. In JavaScript, if you have a parameter that doesn’t have a matching argument, then it’s value is set as undefined. By using this trick, it can save us from the bad code someone wrote to redefine undefined.

Pros
•Gives you the ability to have public and private properties and methods
•The code inside doesn’t use the Object Literal notation
•Keeps undefined’s value as undefined in case someone overrode the value
•Allows you to use $ inside your code without worrying about clashing with other libraries
•Allows your library to grow across files using the “window.namespace = window.namespace || {}” technique
•A common pattern that you will see in many libraries, widgets, and plugins

Cons
•Slightly more complicated pattern, but not overly difficult to understand
If you are interested in digging deeper into some of the patterns I mentioned above then I encourage you to check out Klaus Komenda’s post entitled JavaScript Programming Patterns. The article provides an insightful view of how JavaScript patterns have changed over the years.

Best Practice
In JavaScript it is very important to declare all of your variables and it is considered a best practice to limit the number of objects in the global namespace. Depending on the situation you are developing you may need one or more of the concepts listed above to organize your code and keep it from colliding with other libraries. There is no pattern that is a Silver Bullet, but rather you should assess where you are at and examine the pros and cons of each pattern to address your situation.

2. Not Declaring Arrays & Objects Correctly
JavaScript is a prototypal language and not a classical language like C#. Although JavaScript does have a new operator which looks a lot like C#, you should not use it for creating new objects or arrays.

What Not To Do
You might be tempted to use the new keyword to create your objects in JavaScript.

//Bad way to declare objects and arrays
var person = new Object(),
keys = new Array();
The new keyword was added to the language partially to appease classical languages, but in reality it tends to confuse developers more than help them. Instead, there are native ways in JavaScript to declare objects and arrays and you should use those instead.

Preferred Way
Instead of using the previous syntax, you should instead declare your objects and arrays using their literal notation.

//Preferred way to declare objects and arrays
var person = {},
keys = [];
Using this pattern you actually have a lot of expressive power using Object Literals and array initializer syntax. As we mentioned earlier, you should be careful to know that Object Literals are not JSON.
//Preferred way to declare complex objects and arrays
var person = {
firstName: "Elijah",
lastName: "Manor",
sayFullName: function() {
console.log( this.firstName + " " +
this.lastName );
}
},
keys = ["123", "676", "242", "4e3"];

Best Practice
You should declare all of your variables using their literal notation instead of using the new operation. In a similar fashion you shouldn’t use the new keyword for Boolean, Number, String, or Function. All they do is add additional bloat and slow things down.

The only real reason why you would use the new keyword is if you are creating a new object and you want it to use a constructor that you defined. For more information on this topic you can check out Douglas Crockford's post entitled JavaScript, We Hardly new Ya.

Conclusion
This article has covered some of the common issues you might address coming from C# to JavaScript. I have committed just about everyone of the above Bad Practices myself when I starting to code in JavaScript heavily.

With the recent serge of jQuery hitting the market and other great JavaScript libraries, it is important that we as developers understand the language instead of just thinking that our previous language knowledge will get us by.

This article only covers some of the things you should know. The next post in the series will be published next week. In the meantime please feel free to add comments of any other gotchas that you’ve experience coming from a C# background. I would love to hear about it. Sphere: Related Content