Scaffolding — my approach.

When we write web apps, we often have to create some interface for Creating, Reading, Updating, or Deleting data. In some cases, we do it for every model, so we want to have a way of generating those interfaces automatically.
Most frameworks have some kind of scaffolding, which comes in two forms: - Code generation, which generates code for controllers and views. - Dynamic scaffolding, which outputs some predefined view.

Code generation

  • Pros
    • Flexible, you can modify anything after the generation
    • Theoretically, less complexity in the framework.
  • Cons
    • Generates a lot of repetitive code.
    • Requires external script to generate the code.
    • It's essentially as useful as copy-pasting html code for static websites — everything is fine until you have less than 5 models.

Dynamic scaffolding

  • Pros
    • Simple, almost no code
    • A change in a scaffolding template changes all of them.
  • Cons
    • If you want to customize a view, you must either rewrite whole view, or the view and the controller (depending on the implementation).

In other words, both methods are pretty much useless for bigger projects, where you have many models and most of them require small customizations.
For the last two years, I've used the latter one. The template for listing rows evolved into an ugly combinations of conditionals.
How? One controller wants to have it's list sortable and searchable, other might want to disable searching, and another wants pagination.

You'd think, But I can set some flags to turn features on/off. Well, it works. At least until you have to add something for one and only one controller.

But how to make it more flexible? Because if I want to rewrite part of the view (in the "html code" sense), I have to rewrite the whole, right? Right? Not really, as long as your view isn't just a blob of html code with occasional php echos. Or is it? Because in dynamic scaffolding, that's how the view looks like. A huge html file filled with templating directives, be it php, smarty, or whatever templating system you prefer.

What we'll do here, I'll call Flexible scaffolding. So how it works? It's simple, a class that generates html code. Ok, so you can wrap your template in a class and be happy, but that won't really help. True flexibility can be achieved, when you split the code in small, easily replaceable methods. Let me show you how:

class ListView
{
    protected $data;
 
    function __construct($data)
    {
        $this->data = $data;
    }
 
    function fetch()
    {
       return '<h1>A list.</h1>' . $this->table(); 
    }
 
    function table()
    {
       return '<table>'
            . '<thead>' . $this->header() . '</thead>'
            . '<tbody>' . $this->rows() . '</tbody>'
            . '</table>';
    }
 
    function header()
    {
       return '<tr><th>Each</th> <th>field</th> <th>name</th> <th>here</th></tr>';
    }
 
    function rows()
    {
        $result = '';
        foreach($data as $row) {
           $result .= '<tr>' . $this->row($row) . '</td>';
        }
        return $result;
    }
 
    function row($row) { /* <td>field</td> etc. */ }
 
}
 

The class is longer than a simple template, but it's way easier to modify by inheritance. For example, suppose that we want to swap tbody with thead:

class SwappedListView extends ListView
{
 
    function table()
    {
       return '<table>'
            . '<tbody>' . $this->rows() . '</tbody>'
            . '<thead>' . $this->header() . '</thead>'
            . '</table>';
    }
 
}
 

Now do try and do that with a typical template. Adding to the comparison:

Flexible scaffolding

  • Pros
    • Flexible, OO design.
    • Easy to modify any part of the code, without rewriting the rest.
  • Cons
    • Requires a class for each new modification (ControllerNameActionView?)

Of course, I have only shown how to make flexible views — because most of the time, controllers don't need to be flexible. If you think otherwise, post an example in a comment, and I'll tell you how to solve it with model and view, if possible.

Comments (0)

Project: An lightweight, easy to use PHP5 OpenID library.

Recently, I wanted to add OpenID authentication support to a website I was coding. Therefore I needed a library to handle that.

What I wanted was simply an library that wouldn't generate any kind of errors (including strict ones), and would support both version of OpenID. However, I haven't found any. Of course I have searched at openid.net, which lists all of the libraries that I've tested.

But I still wanted the functionality. So I wrote my own library -- LightOpenID. It works only as a client, as I didn't need to be an OP.
Features:

  • Is easy to use! (you can code a functional client in less than ten lines of code!)
  • Depends only on curl
  • Supports both OpenID 1.1 and 2.0
  • Supports Yadis discovery
  • Supports only stateless/dumb protocol
  • Works with PHP >= 5
  • Generates no errors with error_reporting(E_ALL | E_STRICT)
  • Small -- only one file, one class, and 340 lines of code.

You can get the code at http://gitorious.org/lightopenid

Comments (5)

PHP sukcs.

Suppose you want to pass an argument in an URL, named openid.trust_root. Well, it's an actual name for an argument in OpenID 1.1, which will be passed via GET.

But what happens if gets passed to an php file? You get $_GET['openid.trust_root']?
Nooo... it would be too logical for php to just give us the name passed to an url. So what will we get? $_GET['openid_trust_root'].

Why?
Because we can't have $openid.trust_root (well, we can, but that's another thing). And why would we want such variable? Simply, we don't, but register_globals does. And php modifies name of the parameters to mantain compatibility with something deprecated as of PHP 5.3.0 and defaulting to off since PHP 4.2.0.

But how do I know that? Where to find such information?
Nowhere in the official documentation. Well, there is a description of what is changed in parameters' names (namely, that they're passed through urldecode), but it fails to mention the substitution from . to _. The information however is avaiable in a comment, quoting:

The full list of field-name characters that PHP converts to _ (underscore) is the following (not just dot): chr(32) ( ) (space) chr(46) (.) (dot) chr(91) ([) (open square bracket) chr(128) - chr(159) (various) PHP irreversibly modifies field names containing these characters in an attempt to maintain compatibility with the deprecated register_globals feature.

Of course, parse_str (which is used to parse query strings according to php's rules) behaves the same. At least it's consistent.

Again, php proved to be an illogical, and what's more important, annoying language. Too bad it's the most popular one for the web.

Comments (0)

HTML5 Canvas experiments 2: Metaball generator

It generatoes and displays metaballs in 2D.

Each line in textarea is one metasphere, with following parameters delimited by space: x position, y position, radius, and influence
The last parameter is useful mainly for making negative metaballs. Set to 1 for positive or -1 for negative.

Also, all parameter will be converted to integers.

The generator isn't perfect, but it should work for most of the possible inputs.

And here it is.

Comments (0)

Perlin noise in javascript

I've been experimenting with possibilities of image generation and manipulation in javascript(using <canvas>), and implemented a simple perlin noise generator.

Unfortunately, it seems that it's still to slow for any serious processing -- generating 500x500 noise with cubic interpolation takes more than 10 seconds on my computer.

Comments (0)