Add a Static Page to Symfony

Static pages can be added to Symfony quite easily.

Edit your routing.yml file which is probably located at apps/frontend/config/routing.yml, and add the following routes to add an about, a privacy, and a terms and conditions page.

# static pages
about:
  url:   /about
  param: { module: home, action: page, view: about }
privacy:
  url:   /privacy
  param: { module: home, action: page, view: privacy }
terms:
  url:   /terms
  param: { module: home, action: page, view: terms }

If you are going to keep the generic rules, make sure you add these new rules before the default actions.

Clear your cache:
./symfony clear-cache

Then inside the module named home (create it if it doesn’t exist), add the following action:

  /** 
   * Load a static page.
   * @param sfRequest $request A request object
   */
  public function executePage(sfWebRequest $request)
  {
    $directory = $this->getContext()->getModuleDirectory().DIRECTORY_SEPARATOR."templates";
    $name = $request->getParameter('view');
    // for safety, strip out all non-alphanumeric characters
    $name = preg_replace('/[^a-zA-Z0-9\s]/', '', $name);
    if (is_readable($directory.DIRECTORY_SEPARATOR.$name."Success.php"))
    { 
      return $this->setTemplate($name);
    }
    else
    { 
      $this->forward404();
    }
  }

The template files will be on the home/templates directory, called aboutSuccess.php, privacySuccess.php, and termsSuccess.php

This action will check if the template file exists, and if so load the template, if not it will forward to the 404 not found page. Easy and safe static templates. Add more routes and the appropriate template file as required.

Web Development Best Practices

Choosing a Technology Framework

Does it really matter if you use ASP.NET MVC, Struts 2, Yii, or Rails? Well it might, but for many websites these modern frameworks are just as competitive as the next. Use the stack that is most appropriate for your customer’s situation and is the best choice at the time. Since this is the real world, it will probably change a couple of years in the future.

Leverage Community Extensions

Each framework out there has libraries of modules, extensions or plugins that enhance functionality and provide features that would you otherwise would need to write yourself. If it exists, and it’s in good shape, don’t write it yourself, leverage existing extensions that are appropriately licensed for your project.

Future Proof your URLs

It no longer makes sense to have a web site with extensions, be it .html, .php, .jsp, or .whatever you can think of. Arstechnica even created their own .ars, for no reason that I could tell. Yes the web started with .html because websites were simply serving static files, but that is no longer relevant anymore.

If you build a website with .jsp as the suffix to all URLs, and then a couple of years later your boss wants to re-write the website in python, does that mean you change all URLs to be .py, and setup mass url re-writing schemes to handle the old URLs? No, this would be a nightmare. Protect your future self by completely leaving the actual technology used to build the website outside of the URL.

Another bonus is that these URLs also end up being more SEO friendly!

Use a JavaScript Framework (maybe)

If you are building an AJAX heavy website such as GMail or Facebook, use a JavaScript framework. This is not relevant for many sites that simply use JavaScript to provide some enhanced functionality, but for websites that are heavily dependent upon JavaScript and simply cannot function without it.

I’m not talking about jQuery or Prototype, while those are good libraries that abstract the differences between browsers and provide easy to use functions, they are not built as a comprehensive framework. I’m suggesting you use a framework like JavaScriptMVC, SproutCore, or Spry. These frameworks can be used in tandem with jQuery, but go much farther in helping you organize and control your JavaScript code.

Watch a demo video of what JavaScriptMVC can do for you.

JavaScript Documentation

A call for better JavaScript documentation has gone out and I am 150% in favour of it. Most of the existing JavaScript code, tutorials, and examples available on the web are just messy mashups that work, but are not code you actually want to use in a website. Therefore I am adding the PromoteJS wordpress widget to my blog and I encourage you to do the same.

Learn JavaScript JS

The world needs better JavaScript documentation.

Let’s help others and help ourselves by writing and promoting quality JavaScript documentation.

What Will Web Development Look Like in 5 Years

Developing applications for the web has changed significantly over the last 5 years. Since 2005 the term AJAX has been coined, Ruby on Rails is now an open source web application framework, jQuery was created and has subsequently revolutionized JavaScript development, and now HTML5 is the top buzzword of the day. I believe the next 5 years will hold just as many improvements for web developers.

I foresee a new framework will be created to make developing fully interactive AJAX applications as easy as it is to write current MVC applications. Current frameworks like Ruby on Rails and Symfony provide everything you need to develop a modern application without having to build plumbing infrastructure; however, they do not provide nice components for interactive applications. In addition to a robust server core, this new framework will have a client side JavaScript component that simplifies the process of building interactive web 2.0 applications. Some critical components would be:

  • Form Validation. Libraries do exist to validate forms in JavaScript, but they don’t integrate with the server side form validation. In this new framework you won’t have to write form validation code twice.
  • Paginated Lists. Almost all web applications have at least one page where data needs to be searched and listed with pagination. We need to have this same functionality in JavaScript to skip a full page reload and provide local caching of the results.
  • Animation Library. While script.aculo.us and jQuery have made simple animations and visual effects much easier to do, I believe we can go even farther. Web applications also need to gain that fluidity and soft animations that desktop applications such as Exposé have had for a couple of years.

I also see huge resources being directed towards mobile development because ALL current generation smart phones are built for an incredible web browsing experience. As home users have switched from desktop computers to laptop computers in the last few years, people will slowly start switching to hand-held devices for their primary communication and Internet needs. Most likely this will have one primary effect: web frameworks will have a mobile optimized version of the site done automatically. Little to none developer intervention will be required as only resolution, text sizes, and layouts will be modified for the mobile version.

Lastly I see tools and libraries around 2D and 3D drawing elements. Most likely these libraries would be rendering to a Canvas or a WebGL element but something better could be created. Both of these are young standards right now that show a lot of promise on delivering the ability to draw pixels directly in a native HTML web page. While they will be used first in simple computer games, I am very interested to see what libraries are created to facilitate these elements being used appropriately inside next generation web applications.

What do you think the next 5 years will bring?

The Cost of Endorsing H.264

As you’ve probably heard, both YouTube and Vimeo have released beta support to their massively popular websites to play videos using the HTML5 video tag instead of Flash. While I am glad the video sites are finally switching to the native HTML video tag, I am perplexed why they have gone with the non-free option.

Firefox, Safari, Google Chrome, and soon Opera all support the HTML5 video tag with the ability to play Ogg Theora encoded videos (except Safari). On the other hand, H.264 is only supported by Google Chrome and Safari. Both of these formats do the same thing, they specify a compression standard that allows for efficient playback at relatively small file sizes. There are a number of technical differences, but generally, they preform relatively the same. The big difference between the two is that Ogg Theora is royalty free and available for anybody to use, while H.264 is encumbered by patents held by the MPEG LA association. This same organization will charge anybody who uses it a hefty royalty fee starting in 2011.

If you have a personal blog and want to put a video on your website using H.264 this means you need to have to hire a lawyer to create a deal with the MPEG LA to allow you to use their codec. This will either cost you a lot of money, or they will not allow you to do it. They do have the right to simply deny you if they don’t feel like it.

However, if you use the open Ogg Theora format, you are free to simply upload the video to your website to start using it, the same as uploading an image. Ogg Theora is not covered by any patents and is royalty free.

I don’t understand why both YouTube and Vimeo are both going the non-free route. Is it simply because they have the money to pay MPEG LA? Whatever the case, endorsing H.264 encoded videos as the format for video on the web is an option for large companies with money to pay, but it’s completely the wrong choice for blog writers and any small or medium sized organization.