Here’s a simple example of how to use it:

$purifier = new HTMLPurifier();
$purifier->purify($user_string);

The default Yii Migration command asks the user for a confirmation before running if there are any tables that have been changed, this is quite a sensible default, but I don’t want to be asked if the command should be run after a deployment. Of course it should be.

To see what options can be configured, open the Migrations file

vendors/framework/cli/commands/MigrateCommand.php

Any of the public class variables can be configured in your config/console.php file. Using the commandMap parameter, you can configure values for Yii Commands. Then specify the migrate task, and then the config values you want to change. In this case, I want to change interactive to false, so it won’t ask for a confirmation.

Sample config/console.php:

return array(
 ...
  // database migration, don't ask for confirmation
  'commandMap'=>array(
    'migrate'=>array(
      'class'=>'system.cli.commands.MigrateCommand',
      'interactive'=>false,
    ),
  ),
);

The main configuration file protected/config/main.php returns an array of parameters. Edit this file to merge 2 arrays, 1 from main.php, and another from local.php.

Edit main.php to look like this:

<?php

return CMap::mergeArray(
  array(
    'basePath'=>dirname(__FILE__).DIRECTORY_SEPARATOR.'..',
    'name'=>'Web app',

... other parameters ...

    'params'=>array(
      // this is used in contact page
      'adminEmail'=>'webmaster@example.com',
    ),
  ),
  local_config()
);

// return an array of custom local configuration settings
function local_config()
{
  if (file_exists(dirname(__FILE__).'/local.php'))
  {
    return require_once(dirname(__FILE__).'/local.php');
  }

  return array();
};

And then add any of your own configuration to local.php in the same config directory.

<?php
return array(
  'components'=>array(
    'db'=>array(
      'connectionString' => 'mysql:host=localhost;dbname=db_name',
      'username' => 'my_user',
      'password' => 'secret',
      'enableParamLogging'=>true,
    ),
    'log'=>array(
      'class'=>'CLogRouter',
      'routes'=>array(
        'file'=>array(
          'class'=>'CFileLogRoute',
          'levels'=>'trace, info, error, warning',
        ),
        'profile'=>array(
          'class'=>'CProfileLogRoute',
          'report'=>'summary',
        ),
      ),
    ),
  ),
  'params'=>array(
    // this is used in contact page
    'adminEmail'=>'yourself@example.com',
  ),
);

Here we’ve overridden the adminEmail parameter to yourself@example.com, we’ve added in custom database username and password, and we’ve enabled logging.

Feel free to use this as a straightforward way to add custom config values to your Yii project. Just remember to make local.php an ignored file in Git or Subversion.

We split the template finding code out for code maintainability, and we enhance it on where to look for the file. First it tries to find the template in the language and country eg: en_CA, then it tries to find the template in the matching language, and if that is not found, it falls back to the default language.

/**
 * Load a static page.
 * @param sfRequest $request A request object
 */
public function executePage(sfWebRequest $request)
{
  $template = $this->findTemplate($request->getParameter('view'), $this->getUser()->getCulture());
  $this->forward404Unless($template);
  $this->setTemplate($template);
}

/**
 * Check if a template page exists for a given culture.
 * Be intelligent and check if language & country exist, try language, and then default to english.
 * @param string $name Template filename to check
 * @param string $culture Symfony culture string
 */
protected function findTemplate($name, $culture)
{
  // for safety, strip out all non-alphanumeric characters
  $name = preg_replace('/[^a-zA-Z0-9\s]/', '', $name);

  $directory = $this->getContext()->getModuleDirectory() . DIRECTORY_SEPARATOR ."templates";
  // try language and country: en_CA
  if (is_readable($directory . DIRECTORY_SEPARATOR . $culture. DIRECTORY_SEPARATOR . $name ."Success.php"))
  {
    return $culture. DIRECTORY_SEPARATOR . $name;
  }
  // try langage only: en
  elseif (is_readable($directory . DIRECTORY_SEPARATOR . substr($culture, 0, 2). DIRECTORY_SEPARATOR . $name ."Success.php"))
  {
    return substr($culture, 0, 2). DIRECTORY_SEPARATOR . $name;
  }
  // try default language
  elseif (is_readable($directory . DIRECTORY_SEPARATOR . $name ."Success.php"))
  {
    return $name;
  }
  return false;
}

The template directory should have the default language file as usual, eg: templates/helpSuccess.php, and then there should be folders for each language and possibly language & country with the same filename, but localized. eg: templates/fr/helpSuccess.php

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.

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.

Performance can be increased because your user is going to download the jQuery file from Google’s CDN network and not from your server. Also, it could be even faster if the user visited another website that also uses Google’s hosted jQuery. If that is the case then your user won’t need to download it again and will use the exactly same cached version.

There are two ways to do this.

The fastest and simplest is to link directly to the Google’ hosted jQuery file:

<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"></script>

The second approach has more features but there is a slight delay while the jsapi loads the correct version of jQuery. If you want the absolute best performance use the first version.

1) Signup to get your own API key

2) Add the following code to your layout:

<script type="text/javascript" src="http://www.google.com/jsapi?key=INSERT-YOUR-KEY"></script>
<script type="text/javascript">
google.load("jquery", "1.4.2");

  google.setOnLoadCallback(function() {
    // Put you init code here instead of using $(document).ready()
  });
</script>

You can also specify the latest version of the 1.4 branch:

google.load("jquery", "1.4");

Before we get to the code, validate you have the Ruby Subversion bindings installed correctly by running irb from a terminal:

irb(main):001:0> require ‘svn/client’
=> true

Onto the source code. Start it off by including the required svn modules:

require "svn/core"
require "svn/client"
require "svn/wc"
require "svn/repos"

Then setup the context with your subversion credentials:

ctx = Svn::Client::Context.new()
ctx.add_simple_provider
ctx.auth_baton[Svn::Core::AUTH_PARAM_DEFAULT_USERNAME] = 'username'
ctx.auth_baton[Svn::Core::AUTH_PARAM_DEFAULT_PASSWORD] = 'password'

Now you can run any of the following commands on a remote subversion repository.

SVN Info

repos_uri = 'http://svn.website.com/project/trunk'
revision = 50
begin
  ctx.info(repos_uri, revision) do |path, info|
    puts("Url: #{info.url}")
    puts("Last changed rev: #{info.last_changed_rev}")
    puts("Last changed author: #{info.last_changed_author}")
    puts("Last changed date: #{info.last_changed_date}")
    puts("Kind: #{info.kind}")
  end
rescue Svn::Error => e
  # catch a generic svn error
  raise "Failed to retrieve SVN info at revision " + revision.to_s
end

SVN Checkout

repos_uri = 'http://svn.website.com/project/trunk'
output_dir '/home/billy/project_name'
revision = 50
begin
  ctx.checkout(repos_uri, output_dir, revision.to_i, nil)
rescue Svn::Error::CLIENT_UNRELATED_RESOURCES => e # revision doesn't exist
  raise "No such revision " + revision.to_s + " at " + repos_uri
end

SVN Log

repos_uri = 'http://svn.website.com/project/trunk'
ctx.log(repos_uri, 0, 'HEAD', 0, true, nil) do |changed_paths, rev, author, date, message|
  puts("Revision: #{rev}")
  puts("Author: #{author}")
  puts("Date: #{date}")
  puts("Message: #{message}")
  puts("---------------------------")
end

SVN List

repos_uri = 'http://svn.website.com/project/trunk'
ctx.list(repos_uri, "HEAD") do |path, dirent, lock, abs_path|
  if !path.blank?
    puts("Path: #{path}")
  end
end

That should get you started with the ruby bindings. If you want to know how to do anything else let me know in the comments.

The symfony debug toolbar will look like this when there is a validation error in one of the forms on the current page. This is one of the most incredibly useful features I’ve seen and greatly improves productivity while building forms in the symfony framework. Congratulations to the symfony developers who came up with this tool!

Have symfony 1.1 or 1.2? read catch symfony form errors.

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?