Zeroflux

Life: Version 3.0

2008-07-04T13:07:00Z

I've been a little neglectful of my tiny corner of the web and its loyal readers, so I feel I should update you all with the next phase of my life. 3.0, baby.

The big news is that Rebecca and I are moving out to Halifax, Nova Scotia. Wayyy out east. We live in Victoria (BC) right now, so that's about a 6000 km move.

The reason? Bec got into Dalhousie University to start her fantabulous education/career in architecture. We're both pretty excited about her potential there, as she's consistently staring at, evaluating, and remarking about architecture. She's almost as fanatical as I am with computers. Almost.

But it's all been very bittersweet. We have so many friends, colleagues, and well-wishers (in that they don't wish us any specific harm) here, that it feels like we're throwing away our old lives. We don't know anybody in Halifax, so it should be an interesting progression as we infiltrate a new city.

To make things more interesting, we also bought a used VW Westfalia campervan to take us (and our more-prized possessions) out to Halifax. Exciting, huh?

We searched high and low for the right and found it in Vancouver. It was pretty pricey, but most of the big mechanical stuff had already been done, so we felt it was a worthwhile investment.

On our first test journey (short-haul) out of the city, the damn thing blows the transmission. Ka-blammo. Stuck in 3rd gear. We're sitting on a major highway, in the middle of the lane. We can't drive forward, we can't roll backward. So we call a tow truck and sit on the side of the road for 45 minutes, hoping the Westy doesn't get hit by an 18-wheeler.

Long story short, we ended up replacing the transmission, which, as it turns out, is quite expensive. We took an extra week in Salmon Arm waiting for it to get fixed, which actually turned out to be the silver lining, as I got to spend some more time with my family.

And now here I sit, on the floor of a mostly-empty apartment, staring at boxes and thinking about how I have to live with only one active computer for the next month or so. Talk about arduous.

So wish us luck, dear readers. We're sailing the asphalt seas in a 20-year-old hippie van, across the country to a city full of strangers. Version 2.0 is over. It's time for version 3.0.

New Pronto Snapshot: 20080428

2008-04-28T11:04:48Z

I've been busy lately, but still steadily working on the ol' web framework. I'm starting to reorganize the core components to maintain a loose coupling between layers. Behold an incremental improvement! Huzzah!

Changes:

Change in nomenclature: "template plugins" are now also known as "helpers", and "page plugins" are now also known as simply "plugins"
Added a datetime widget to the Form helper
Moved template logic into a separate class so it can be accessed outside of page controllers (eg, a commandline client can now use it to render email content)
CSS fixes for IE6 and IE7 (oh how I hate thee)
Changed Mailer plugin to use SwiftMailer instead of PHPMailer. PHPMailer is still available via ppPHPMailer for the time being.
Upgraded TinyMCE to 3.0.7
Changes to display callback functions in tpGrid::build_grid()
More bugfixes

Now that input validation and templates are where they should be, I'd like to focus on URL mobility a bit more. Mapping URLs to controller/action pairs is dead easy, but templates and controllers still hardcode URLs in many cases. For example, if an action redirects to another controller/action after it has finished its business, then it hardcodes that URL. Works most of the time, but if I want to move a controller to a new URL location (eg, move /blog/post/edit to /admin/blog/post/edit) then I have to actually go through the code and change all instances of that URL.

My answer is going to be basically the reverse of the current URL->Controller mapping that's currently found in app/config/urls.php. So instead of rendering a hardcoded URL like /blog/post/edit, you would ask to render the controller Blog_Post and the action Edit.

Sounds good in theory. I'll let you know how it works out.

Pronto Lives

2008-03-26T09:03:21Z

In between my gazillion contracts and side projects, I've managed to eek out a little site for my latest toy, Pronto. Welcome to it!

The site now lives at www.prontoproject.com. There's not a ton of stuff there yet, but I will expand the site whenever I can find the time. For now, you can poke at an SVN snapshot of Pronto and play with an example app, a dumb little knowledge base. I like to learn by example, so I plan to release a few more mini apps that show Pronto in action.

In case you haven't been keeping up, Pronto is yet another PHP web framework. You may roll your eyes and say "Oh God, another web framework?" and you're probably right. But I came from the world of linux distributions, and at last count, I think DistroWatch tracked about 550 of them. So plenty of room left in the framework world! ;)

And now, to round out this post a bit, some back story...

I started Pronto about 18 months ago. I'd been doing solid web contract work for some time and was using CakePHP as my primary weapon. I'd also used Mojavi and Symfony in the past, and flirted with Django as well. Django was pretty cool, but when you're building websites at varying levels (mom-n-pops right up to huge ecommerce retailers) you often have to use something more ubiquitous and understood. mod_python (and certainly Ruby) still weren't widespread enough to make deployment trivial, so it was PHP. In fact, in many cases it was still PHP4.

Aside: It seems that the PHP world is caught in a weird cycle where we can't get out of PHP4, despite the long-standing availability of PHP5 and many obvious reasons to upgrade. If you haven't seen it yet, check out gophp5.org. They explain the problem quite well.

So I ended up using CakePHP for most projects, since it was fairly easy to use and it supported PHP4. I didn't end up using it for long before I found WebPHP, which was simply a PHP port of WebPy, a popular, lightweight Python web framework (actually, more of a dispatcher). I enjoyed the simplicity of it and started using it for some smaller stuff that didn't require Cake.

In my classic itch-scratching fashion, I ended up adding pieces to my pseudo-framework in a get-the-job-done mentality. But it started looking kind of elegant, and soon I was abandoning Cake in favour of my own, as-yet-unnamed framework.

I found the code reusability was great, even better than what I had with Cake, and the template plugins gave me big gains in development time, saving me from the most tedious parts of web development: crafting the forms and tables/grids that are so commonly needed in any web app.

And so it went. I kept working on Pronto, intending it to be a personal tool/project. But then it started to round out and look semi-professional, so I began to clean it up and document it. The hopes being, of course, to garner a community around it so bright minds will help clean up and improve various facets. I even tried to correct my mistakes of the past by writing a manual early on in the game. Documentation is a classic weakness of mine. To this day I still use Pronto's code is a primary reference point, but I'm trying to use the manual and API docs more and more, hoping that I will improve them more if I personally use them. I'll let you know how that works out.

In summary, welcome to Pronto. You may hate it, you may like it. You may not even care because you're not a web developer, in which case, I just stole 10 minutes of your life. Hah!

SXSW 2008 and Updates

2008-03-05T15:03:14Z

Hey, long time no post. There are typically two reasons why a blogger goes AWOL for a while:

They have nothing worthwhile to write about; or
They are in head-down, get-stuff-done mode

I'm leaning towards the latter, but there may be a hint of the former in there as well.

I've been backing out of my contract work a bit lately and focusing on a new startup called EnviroSpeak. It's yet another social/video/blog style of website but with a focus on environmental problems and solutions. We're shooting for a beta launch sometime this month, so stay tuned.

I've also been working on getting Pronto documented so I can release it. EnviroSpeak, among other sites, are already using it, so I believe it is now production-quality. Stay tuned for updates!

And finally... 2008 will mark my first year as an attendee at South by Southwest Interactive. So if you're around, look for the lanky guy with the Vaio and say Hi. I'll be hanging around the nerdy panels and the nuclear taco party.

PHP and UTF-8 Tips

2007-12-07T16:12:38Z

Many PHP-based web applications use ISO-8859-1 as the character set, as this is pretty much the default in North America and Western Europe, as I understand it. The problem is that this doesn't work out so well down the road if you intend to internationalize your web application. What if someone wants to write a blog comment in Greek, or drop a little Chinese in there? You'll probably end up with a bunch of weird diamond-shaped blocks or odd-looking question marks, depending on your browser.

Nowadays everybody is pretty much in agreement that UTF-8 seems to be the way to go. It's backwards-compatible with 7-bit ASCII and it can handle all the other character encodings out there, so you don't have to juggle them all anymore. So with the choice of ultimate charset out of the way, it's just a matter of convincing your RDBMS and scripting language to agree on the same charset.

First, start at the data layer. Ours is MySQL.

1. Table Definitions

In MySQL, you can append the CHARACTER SET keyword to your CREATE TABLE statements.

DROP TABLE IF EXISTS `sessions`;
CREATE TABLE `sessions` (
    `id` CHAR(255) NOT NULL,
    `lastupdate` INT UNSIGNED NOT NULL,
    `data` BLOB,
    PRIMARY KEY(`id`),
    KEY(`lastupdate`)
) DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;

2. VARCHAR Isn't Always Your Friend

I've been told that CHAR, VARCHAR, and TEXT can be a little misguided in their attempts to automagically convert encodings for you. If you want to be absolutely sure that what you put into MySQL is what you get out of it, then it's a good idea to use BINARY instead of CHAR.

Instead of CHAR, use BINARY
Instead of VARCHAR, use VARBINARY
Instead of TEXT, use BLOB

There are downsides to using binary field definitions instead of text. A big one for me is no collation, meaning you can't sort on those fields. If you need this, I'd recommend you stay with VARCHAR et al. I usually do as well, but I thought I'd mention this one since I've seen it used this way in other applications (eg, MediaWiki).

That pretty much does it for MySQL. In PHP, there are a few tricks that can help you out.

3. Default Character Set

If you don't explicitly throw out a Content-Type header to the browser, PHP will send one for you. And chances are, it's going to send one like this:

Content-Type: text/html; charset=ISO-8859-1

Instead of littering your code with header() calls wherever you deem necessary, you can use the default_charset setting to tell PHP you're a UTF-8 guy now.

<?php
  // UTF-8, please!
  ini_set('default_charset', 'UTF-8');
?>

Now if PHP sends out Content-Type headers on your behalf, it will use this character set. It's also a good idea to throw a META tag in your HTML too:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

4. Multibyte String Functions

If you're working with UTF-8 strings, PHP's standard string functions won't do you any favours. Try chucking a multibyte string into strlen() and what happens. PHP expects single byte, so it will return an incorrect result.

Fortunately, PHP's mbstring extension provides another set of string functions that can handle multibyte strings. They follow the same naming pattern as the standard string functions, except they're prefixed with mb_. Eg, mb_strlen().

It's kind of a pain to search-and-replace all your string functions for their multibyte counterparts, but the PHP developers have realized this as well and accomodated. If you have the mbstring extension, you can ask PHP to overload all the standard string functions with their mbstring counterparts. This means you can call substr() as you normally would and PHP will actually call mb_substr() instead, saving you the search-and-replace work.

<?php
  // Override standard string functions
  if(extension_loaded('mbstring')) {
    ini_set('mbstring.func_overload', 7);
  }
?>

For the reasoning behind the '7' in that call, see the PHP reference for mbstring.

I'm sure there are some more conveniences that could be used to gracefully glide into the world of UTF-8. Anyone have any?

Pronto: Templates and Plugins

2007-11-07T10:11:04Z

So in our past episodes, we covered the basics of page controllers and data models, so it's probably time to go over templates.

Templates are pretty basic -- they don't vary much from framework to framework, except for the choice of template language: native PHP or a third-party markup such as Smarty?

My choice is native PHP. I see no reason to introduce another layer of abstraction when proper PHP is just as easy to read or write. The plus side is you get to avoid the performance detriments (and extra caching layers used as workarounds) of parsing another type of markup. If you look at something like Smarty, all it's really doing is parsing your template code for Smarty tags and converting them to native PHP. Why not skip that step?

This also gives us greater flexibiliy in the template, as we can now create PHP functions, call template plugins, and do some snazzy PHP stuff that probably isn't possible in a templating layer.

Like most web frameworks, Pronto organizes templates into directories, usually named after the page controller that renders them. Templates are usually rendered inside of layouts (or "base templates"), which serve as a container for the repetitive content of a web app -- you know, all the html that's responsible for the general layout and structure of the web page, but not the content within.

A quick layout example:

<html>
<head>
  <title>My Web App</title>
  <?php echo $html->css('site') ?>
  <?php echo $html->js('jquery') ?>
  <?php echo $HTML_HEAD ?>
</head>
<body>
  <h1>My Site Header</h1>
  <?php echo $CONTENT_FOR_LAYOUT ?>
</body>
</html>

This is pretty basic stuff. You can see we're using a template plugin ($html) in the head as a shortcut to render some CSS and script tags. The special $HTML_HEAD variable will be filled in by Pronto at render time, replaced with any HTML/JS/CSS code that may be required by various widgets. We can talk more about template code scheduling later. And finally, the $CONTENT_FOR_LAYOUT variable is replaced by the actual content of the rendered template. This variable only appears in template layouts, not regular templates.

So now that we have a layout, how do we render a normal template from a page controller? Like this.

<?php
class pSandbox extends Page
{
  function __init__() {
    // set a common layout for this entire controller
    $this->web->base_template = 'layout.php';
  }
  function GET_helloworld() {
    $this->tset('recipient', 'World');
    $this->render('sandbox/hello.php');
  }
}
?>

We set a layout file in the __init__() method, though we didn't really need to. A site-wide default is set in the entry script (index.php) so we only need to set it if we're using something other than the default layout.php. Then, in our action method GET_helloworld(), we use the Page::tset() method to set a template variable. Template variables will be passed through to the template file when it is rendered.

And here are the contents of our templates/sandbox/hello.php file:

<p>Hello, <?php echo $recipient ?>!</p>

As you can see, we access our template variables just as we would any other global variable. You're free to use any other PHP code you like, but you cannot (well, should not) access variables from the dispatcher, models, or page controllers. Templates should use template variables (and plugins) only, nothing else.

Now, let's do something more interesting by taking advantage of the template plugins. There are currently four template plugins that come with Pronto, but you can add as many as you want. The four base ones are html, form, table, and ajax. Their uses are fairly self-explanatory.

html	Generate basic HTML elements -- images, links, javascript, css, urls
form	Generate form elements and entire forms
table	Generate basic tables and more advanced record grids
ajax	Generate AJAX widgets such as dialogs (this module is still in a developmental state)

Let's take the old Create Person form and spruce it up a bit. The new template is below, and here's what it looks like.

<?php if(isset($data['id'])): ?>
  <h2>Edit Person</h2>
<?php else: ?>
  <h2>Create a New Person</h2>
<?php endif ?>
<?php
$f = array(
  'action'  => $html->url(CURRENT_URL),
  'submit'  => array('Create Person','Update Person'),
  'data_id' => $data['id'],
  'options' => array('numcols'=>2),
  'layout'  => array(
    'col1' => array('colspan'=>1),
    'col2' => array('colspan'=>1),
    'col3' => array('colspan'=>2),
  ),
  'elements' => array(
    'col1' => array(
      'name'        => array('prompt'=>'Name:', 'type'=>'text'),
      'address'     => array('prompt'=>'Address:', 'type'=>'text'),
      'city'        => array('prompt'=>'City:', 'type'=>'text'),
      'country'     => array('prompt'=>'Country:', 'type'=>'text'),
      'signup_date' => array('prompt'=>'Signup Date:', 'type'=>'date','help'=>'This is a help popup')
    ),
    'col2' => array(
      'fav_color' => array('prompt'=>'Favourite Colour:', 'type'=>'color', 'help'=>'An example of a colour selection widget'),
      'birthdate' => array('prompt'=>'Birthdate:', 'type'=>'date'),
      'fav_foods' => array('prompt'=>'Favourite Foods:', 'type'=>'multiselect', 'options'=>array_hash(array('Pizza','Sushi','Lasagna','Lobster','Hamburgers','Caviar'))),
      'other'     => array('prompt'=>'Other:', 'type'=>'text'),
    ),
    'col3' => array(
      'about'     => array('prompt'=>'About:', 'type'=>'htmlarea', 'attribs'=>array('style'=>'width:800px;height:300px')),
    )
  )
);
echo $form->build_form($f, $data, $errors);
?>

As you can see, the $form->build_form() function can generate some decent-looking forms without much more than a basic form definition. It supports tooltip-style context help, various widget types (both simple and complex) and it can do rudimentary multi-column, tableless layouts.

Now let's make one more change. This time, we'll split the form up into separate tabs. Result is here.

<?php if(isset($data['id'])): ?>
  <h2>Edit Person</h2>
<?php else: ?>
  <h2>Create a New Person</h2>
<?php endif ?>
<?php
$f1 = array(
  'data_id' => $data['id'],
  'options' => array('noopen'=>true,'noclose'=>true,'numcols'=>2),
  'elements' => array(
    'col1' => array(
      'name'        => array('prompt'=>'Name:', 'type'=>'text'),
      'address'     => array('prompt'=>'Address:', 'type'=>'text'),
      'city'        => array('prompt'=>'City:', 'type'=>'text'),
      'country'     => array('prompt'=>'Country:', 'type'=>'text'),
      'signup_date' => array('prompt'=>'Signup Date:', 'type'=>'date','help'=>'This is a help popup')
    ),
    'col2' => array(
      'fav_color' => array('prompt'=>'Favourite Colour:', 'type'=>'color', 'help'=>'An example of a colour selection widget'),
      'birthdate' => array('prompt'=>'Birthdate:', 'type'=>'date'),
      'fav_foods' => array('prompt'=>'Favourite Foods:', 'type'=>'multiselect', 'options'=>array_hash(array('Pizza','Sushi','Lasagna','Lobster','Hamburgers','Caviar'))),
      'other'     => array('prompt'=>'Other', 'type'=>'text'),
  ))
);
$f2 = array(
  'data_id' => $data['id'],
  'options' => array('noopen'=>true,'noclose'=>true),
  'elements' => array(
    'about' => array('prompt'=>'About:', 'type'=>'htmlarea', 'attribs'=>array('style'=>'width:800px;height:300px')),
  )
);
?>
<form method="post" action="<?php echo $html->url(CURRENT_URL) ?>">
<div id="form_container">
  <ul>
    <li><a href="#tab1">Basic Info</a></li>
    <li><a href="#tab2">Other Stuff</a></li>
  </ul>
  <div id="tab1" style="background:#fff" class="form">
    <?php echo $form->build_form($f1, $data, $errors) ?>
    <br style="clear:both" />
  </div>
  <div id="tab2" style="background:#fff" class="form">
    <?php echo $form->build_form($f2, $data, $errors) ?>
    <br style="clear:both" />
  </div>
</div>
<br />
<?php echo $form->submit('submit', 'Update Person', array('style'=>'float:right')) ?>
</form>
<?php $html->js_run('jq_tabs', "$('#form_container').tabs();") ?>

This one is a little longer due to the tab setup, but it's pretty self-explanatory. You can see we're now building two forms but they exist under the same <form> tag since we asked build_form not to "open" or "close" the subforms. And at the very bottom, you see how we can queue some JavaScript to be run once the DOM is loaded. It's important to use Pronto's JS queueing system instead of just throwing out the necessary JS in a <script>. The reason is that Pronto can make sure the JS code is run properly if this template is returned as an AJAX response.

You'll also notice that the line of JavaScript we're running is using jQuery. I heart jQuery, so Pronto does too.

Now let's make the list/edit process a little more fluid. We'll take another look at the grid template we use to list all records, but this time we'll add an another edit action that uses AJAX instead of a normal request.

No changes are required to our new tab-based create/edit template, but we have to make a few alterations to the grid template. It's shown below.

<?php $form->htmlarea_preload() ?>
<h1>People</h1>
<?php echo $html->link_button('New Person', '/person/create/tabs', 'icons/add.gif', '', false, array('style'=>'float:right')) ?>
<br /><br />
<?php
echo $table->build_grid(array(
  'url'      => $html->url(CURRENT_URL),
  'rowclick' => $html->url('/person/edit/tabs?id=_ID_'),
  'options'  => array('ajax'=>true),
  'columns'  => array(
    '_OPTIONS_' => array(
      'edit'   => $html->link($html->image('icons/edit.gif', array('title'=>'Edit Person','class'=>'ajax_action')), '/person/edit/tabs?id=_ID_'),
      'delete' => $html->link($html->image('icons/delete.gif', array('title'=>'Delete Person')), '/person/delete?id=_ID_', 'Are you sure?')),
    'name'        => array('label'=>'Name','type'=>'text'),
    'address'     => array('label'=>'Address','type'=>'text'),
    'city'        => array('label'=>'City','type'=>'text'),
    'country'     => array('label'=>'Country','type'=>'text'),
    'signup_date' => array('label'=>'Signup Date','type'=>'date'),
  ),
  'id'      => 'id',
  'data'    => $data,
  'perpage' => $perpage,
  'curpage' => $curpage,
  'rows'    => $totalrows
));
?>

And here are the results. Click the "edit" icon beside any record and you should see the form popup below the record you selected. Kinda cool, huh? If you are unfortunate enough to be using IE, you'll probably get a JS error when trying to load that last form via AJAX. This is a bug in the htmlarea widget that I haven't fixed yet. Find yourself a better browser.

I think that's enough PHP code for one post. As you can see, Pronto tries hard to eliminate any mundane or repetitive HTML in the template layer. It can't do everything and often there's no better solution than to sit down and hack out the HTML yourself, but for rapid application development, these template plugins are a big time-saver.

String Theory is Cooler than You

2007-10-26T13:10:35Z

If you're into theoretical physics (at the armchair level) and string theory, then this 12-minute video is a must. Thanks Hapy!

To see some more short videos explaining string theory, check out the winners of the string theory contest.

A real-world example: TipCache

2007-10-24T14:10:54Z

Here's an example of Pronto in real-world use. Though most uses of Pronto at present are for client websites, TipCache was a personal site of mine that I whipped up one afternoon last Spring.

It's about the quickest site one could write while still calling it "dynamic" -- it has two basic entities, users and tips. The whole function of the site is to provide an easily-searchable database of quick, one-off tips and howtos related to IT.

The reason I wrote it was due to the amount of time I was spending looking for the more esoteric answers to some sysadmin-related issues I was having. Google is a programmer's best friend in most cases, but there are often times when one has a problem that is just too edge-case to show up in the first few pages of a Google search. I end up poring through mailing list archives and dead forums, just trying to get a sniff in the right direction. And many of the results take me to a site like experts-exchange, which wants me to signup and pay just to see the answer!

TipCache is my answer. Its purpose is to hold tips for others to find. No catches, no forced registrations, easily searchable through standard tagging. If the site proves useful to others, I plan to add a little more to it -- feedback/reputation ratings for tips/contributors, comments/corrections, etc.

If you have any technical tips/howtos that others may benefit from, please do add them to the site. TipCache uses the well-known Markdown syntax for clean, non-HTML markup and its a cinch to add new tips.

Pronto: Data Models

2007-10-23T09:10:34Z

Since Ruby on Rails first came out, many frameworks have adopted its ActiveRecord data modeling system. I've never used Rails, but I did spend some time with CakePHP, which has a similar ORM scheme.

I realize the potential power of such a model, but its never really done me any favours. And since it's my party, I've left out any complicated ORM stuff from Pronto. We have data models, but they are relatively dumb compared to some of the ORM stuff I've seen in other frameworks.

Why? Personally, I believe typical SQL isn't very hard to write, so I craft it manually for each and every data model I have in a project. I find this just as easy (and sometimes easier) than trying to define all the inter-entity relations in some weird format. Writing a SQL join is usually fast and easy, and if I lay out my data models correctly, I only have to do it once per relation, then I just call the proper methods in my data models and I have the same functionality as I would with a more dynamic ORM approach.

Unless you have a compelling reason not to, each entity in your project should have a corresponding data model. These models are imported by page controllers and used by them to manipulate the data. So here's the plot summary so far: Dispatcher receives a request, passes control to a page controller; the page controller imports data models and manipulates data through them, then renders a template which is sent back to the browser. A pretty standard MVC dance.

Here's a basic vanilla data model, as generated by Pronto:

<?php

class mPerson extends Model
{
  var $default_sort = 'name ASC';
  var $table        = 'people';

  function validate_for_insert($data)
  {
    $errors = array();
    $this->page->required($errors, array('name','address','city','country'));
    $this->page->validate($errors, 'email', VALID_EMAIL, 'Valid email address is required');
    return $errors;
  }

  function validate_for_update($data)
  {
    $errors = array();
    $this->page->required($errors, array('name','address','city','country'));
    $this->page->validate($errors, 'email', VALID_EMAIL, 'Valid email address is required');
    return $errors;
  }

  function insert($data)
  {
    return parent::insert($data);
  }

  function update($data)
  {
    return parent::update($data);
  }

  function delete($id)
  {
    parent::delete($id);
  }

  function list_data()
  {
    $from   = $this->table;
    $exprs  = array();
    $select = '*';
    foreach($exprs as $k=>$v) {
      $select .= ",$v $k";
    }
    return array($exprs, $select, $from);
  }
}

?>

Pretty boring. This file was generated by Pronto, so most of the content is just placeholder stuff to be extended from the parent class, Model. You can see some basic data validation stuff, which uses Page::required() and Page::validate() to ensure incoming form data isn't erroneous. You can also see some basic methods for data manipulation: insert, update, get, and delete. Any data model should have these methods, especially if you're using the Page_CRUD class to manipulate the data, as it will expect these methods to be functional.

If a model needs to join with other entities/tables or provide some special access methods, then the model class is where this logic will go. As an example, let's assume we always need to see all address records associated with a person. Might as well change the get() method to pull these in.

<?php
  function get($id) {
    $person = parent::get($id);
    $person['addresses'] = $this->db->GetAll("SELECT * FROM addresses WHERE person_id=%i", array($person['id']));
    return $person;
  }
?>

Not terribly difficult. And how do we access a model from a page controller? Like this:

<?php
class pPerson extends Page
{
  function __init__()
  {
    $this->import_model('person');
  }
  function GET_view()
  {
    $person = $this->models->person->get($this->param('id'));
  }
}
?>

Now if we're following the rule to always have a distiinct model for each entity, then we should have a data model for addresses too. Models can depend on other models, so let's rewrite our mPerson::get() method to use the address model to load in addresses, instead of grabbing them from a foreign table in mPerson:

<?php
  function get($id) {
    $person = parent::get($id);
    $this->depend('address');
    $person['addresses'] = $this->depends->address->get_all_by('person_id', $person['id'])
    return $person;
  }
?>

There are a number of methods in the base Model class that will take care of any mundane SQL, leaving you, the developer, the task of writing the more interesting ones.

Now let's look at that weird list_data() method in mPerson. This method's purpose is to return any and all columns that will be used when creating a table/grid/list of records for this entity. As you can see above, it returns three items in an array: a list of expressions, a SELECT clause, and a FROM clause. All three of these items are destined to be passed straight through to the database layer, so they should be in well-formed SQL. Once again, the reason for this method is better illustrated with a good example.

<?php
  function list_data()
  {
    $from = "people p INNER JOIN addresses a ON (a.person_id=p.id AND a.is_primary)";
    $exprs = array(
      'full_name'       => 'CONCAT(p.first_name," ",p.last_name)',
      'primary_address' => 'CONCAT_WS(",",a.street,a.city,a.state)'
    );
    $select = "p.*";
    foreach($exprs as $k=>$v) $select .= ",$v $k";
    return array($exprs, $select, $from);
  }
?>

Now any interface that wants to create a list of records for this entity can ask the model for the proper list data before it queries the database. Currently the only class that does this is Page_CRUD, but custom classes are free to use this function if it makes sense.

By now you've also seen a quick usage of the database class, referenced as $this->db in mPerson. This is the class that actually talks to the database server, whatever it may be. It uses SafeSQL to protect against injection attacks and it's fairly robust for basic DB work. If you're a stringent MVC follower, then you'll probably only need to use $this->db in data models, but it is available to most objects throughout Pronto.

And so concludes a basic introduction to the lightweight data model. While it doesn't do everything under the sun, it is lean and mean and makes sure your page controllers aren't littered with SQL or redundant data-manipulation code.

Facelift

2007-10-19T13:10:18Z

Website designs tend to get a bit stale, especially if you stare at them a lot. Here is this year's incarnation of Zeroflux.

I've tested it in Firefox, Opera, and Safari and it looks good in all three. If you're using IE and it doesn't look good, then switch to another browser.

Thanks to Styleshout for the base design.