Joseph Hallenbeck


October 13, 2014

DropFramwork

Filed under: Software Development — Tags: , , , — Joseph @ 6:00 pm

Flattr this!

This summer, I plunged into the depths of my back up drives and came up with some old projects that were growing some dust. Like most old projects, I find them, get excited. Decide to do a major revolutionary revamp, and ultimately just end up touching up some things and kicking them out the door. The DropFramework is one such thing. For a long time, I wanted to make my own micro-framework to compete with the likes of Slim or Silex. In the end though, I really feel that those two have the space of micro-frameworks very well covered. No one needs yet another PHP micro-framework with half-done ideas floating around. Still, I did want to show it off, so I polished it up a little bit and through it up on github. Below are my thoughts on “Yet Another PHP Microframework:”

Yet Another PHP Microframework

For all intensive purposes, you can consider this an abandoned project and I would not recommend anyone actually use this in production.

A few years ago when Code Igniter was still quite a hot thing and a lot of
servers were still running PHP 5.2, e.g. the “dark ages” before we got all the nice things that came along in PHP 5.3 it seemed to be quite the fashion for everyone to try their hand at writing their own framework.

This was my go at it.

You will find a lot of similarities with Code Igniter (since that is the framework I worked with at the time) and you might also find a lot of classes that look like they came straight out of PHP Objects, Patterns and Practice since that was my bible.

I wanted to do a few things in writing the DropFramework:

  1. I wanted to better understand the MVC pattern, the choices being made and how CI works.
  2. I wanted a framework that was small enough that I could read and understand every class in it.
  3. I wanted a framework with a very small footprint that worked by transforming HTTP requests into request objects / command objects. This allowed me to fire up multiple instances of the framework per HTTP request with the master application generating it’s own request objects that it would feed into it’s child instances and then construct a document out of the application responses from the children.
  4. I did not like at the time, and still do not like the major design patterns of a lot of ORM solutions which tend to treat the database as the authoritative model of the data. I rather turn this convention upside down: treat the database as just another form of user input. The model can then be constructed from any form of input — the database, an HTTP post, a file. The PHP object is then the authoritative source for how the data structure relates with other data. Any data coming into the model passes through a validation layer that translates it (or rejects it if it invalid).

Whether or not I succeeded at this items? I don’t think I would really know.

Version 0.4.0

The version of the framework that had been sitting on my hard disk for some time was 0.3.0. In deciding to release it I have done two major things:

  1. I created a simple example of the framework working. The code for this example is also up on github and a live version as well.
  2. I namespaced the entire framework and brought it into PSR-4 compliance allowing for installation via Composer and the use of the Composer autoloader. This defeats a lot of the purpose of the PHP 5.2 era frameworks which devoted a lot of their resources to locating and managing the loading of assets. This, of course, makes this no longer a PHP 5.2 compatible framework and probably even makes a lot of the framework look rather silly.

April 22, 2014

Wanted: An Unobtrusive Javascript Framework

Filed under: Software Development — Tags: , , , — Joseph @ 9:42 pm

Flattr this!

I decided to spend the last couple of weeks introducing myself to some of the big MVC Javascript Frameworks that have gotten so much traction over the last couple of years. I sadly, have found the field littered with frameworks that happily violate the principle of Unobtrusive Javascript and am wondering — is there any solid MVC Javascript Framework that is clean and unobtrusive, will I need to keep rolling my own, or am I just a Luddite?

Unobtrusive Javascript

Now first, I must admit that I feel as though I am a technological Luddite when it comes to the rise of Javascript. When I started making websites the standard advice was to keep as much of the document generation on the server-side as possible and to practice what is called “unobtrusive” Javascript.

The idea of unobtrusive Javascript has been a paramount item of good front-end design. Namely, that you clearly separate your concerns and avoid reliance on server-side scripts. HTML ought be semantically distinct from style or behavior and we do this by keeping our markup in one file, our style-sheets in another, and our Javascript in a third file. We do not inline our styles nor our Javascript and we try to keep them distinct so that even if the style-sheet or Javascript never loads the unstyled, un-scripted document is still in a usable state.

The earlier concept, simply keeping things separated decouples the reliance of our code on any one element. We can change the markup, the style, or the behavior of our application without necessarily impacting the other two elements.

The latter idea is a concept refereed to as failing gracefully. Namely, it is that we put fall backs into our application such that if the Javascript does not work, the user can still make use of the web application. There’s a lot of ways that we can do something like this:

  • Have an ajax form submit normally if the browser does not support ajax
  • Add form submit buttons that are hidden using Javascript on load.
  • Make sure client-side generated content has some kind of fall-back view that is generated server-side

The list goes on and on, but you begin to get the idea. Vasilis van Gemert has opened a great discussion about arguments against building Javascript based documents and his comments section is ripe with the reasons that unobtrusive Javascript is still very much relevant to the day-to-day development of websites.

Obtrusive Javascript is where you get page behaviors and views that are only accessibly if the client has Javascript support. The result of these websites is that they are completely un-usable without their supporting Javascript files. We can see this on websites that:

  • Only allow a form to be submitted via a Javascript call
  • Links whose destination is dynamically generated with Javascript
  • Views that are created by generating and appending DOM elements client-side rather than server-side

Now, I grant that unobtrusive Javascript can be hard. Sometimes there just isn’t a suitable fallback. Some times you are running late on a project and the fact that it runs fine on 99% of the browsers means it’s time to just shove it out the door and be on your way. However, I do believe it is a good idea to keep the principle of separating concerns and failing gracefully in mind whenever adding client-side behaviors to an application.

State of Affairs for Javascript MVC

I will address in some article my own personal solutions to structuring a Javascript application as well as the challenge of coming up with a solid framework for addressing UX and DOM manipulation without turning into spaghetti code or re-inventing the solution with each website. Yet, it is typically a good idea to go with a community framework in a team environment since it offers a familiar structure between projects and programmers on a team. For this reason, I embarked on working my way through some of the more popular Javascript MVC frameworks to see what they offer and decide which one, if any offers an unobtrusive solution. My concern is that on a cursory look (AngularJS and EmberJS) both seem to scatter Javascript snippets throughout the document and in the latter case invents a whole new template language that it injects into a script tag. Oh dear.

The only Javascript framework that I have come upon that makes any attempt at keeping any kind of unobtrusive fallback seems to be Knockout.js. That said, it is not the sexiest of new frameworks out there.

Knockout.js

Example:

HTML

<p>First name: <input data-bind="value: firstName" /></p>
<p>Last name: <input data-bind="value: lastName" /></p>
<p>Full name: <strong data-bind="text: fullName"></strong></p>

Javascript

// This is a simple *viewmodel*
function AppViewModel() {
  this.firstName = ko.observable("Bert");
  this.lastName = ko.observable("Bertington");
  this.fullName = ko.computed( function() {
    return this.firstName() + " " + this.lastName();
  }, this);
  this.capitalizeLastName = function() {
    var currentVal = this.lastName();
    this.lastName( currentVal.toUpperCase() );
  }
}

// Activates knockout.js
ko.applyBindings(new AppViewModel());

Knockout works by using the data attribute to bind to DOM elements. This means that if the Javascript happens to fail we are still left with your typical document with typical document behaviors. Take the above example clip. If the data-bind attributes are ignored we would still get a form with a first and last name. Indeed, we could even fill that form in server side by assigning value="Bert" and value="Bertington" to the first name and last name inputs.

On top of this, there is something about Knockout that just makes sense. It isn’t as flashy as Angular or Ember. It doesn’t seem to incorporate any new trendy templating systems, massive API libraries, or require us to create half a dozen separate Java script files for controllers, models, and parts of views.


November 25, 2013

Improving Upon CodeIgniter’s Validation

Filed under: Software Development — Tags: , , , — Joseph @ 9:49 am

Flattr this!

In this article I plan on addressing CodeIgniter’s shortfalls as a framework for validating objects and introduce a method for improving the validator classes re-usability.

When To Validate?

The answer to this question is simple: whenever we are dealing with input. The (incorrect) assumption that CodeIgniter and many web-applications make is that user input comes in the form of GET and POST variables and a considerable amount of effort goes into validating inputs via these routes. However, GET and POST are not the only sources for user input. User input can come via external sources such as tying into a remote API, an RSS feed, or from the database itself. From each of these sources we could get an invalid state. In the case of the remote API or RSS feed this is easy to understand. The API could change, or the RSS feed could be malformed. In the case of the database the issue typically appears when data is stored into the database under one context but is then accessed with a different expectation.

Take for example a database with the following table:

CREATE TABLE IF NOT EXISTS `persons` (
  `id` int(10) NOT NULL AUTO_INCREMENT,  
  `name` varchar(256) NOT NULL,
  `birthdate` DATE NOT NULL,  
PRIMARY KEY (`id`) ) ;

Now say that we inserted a person with name “Bob” and birthdate “1975-01-01.” This passes the validator going into the database, but later on we pull this row from the database and use it to construct a plain PHP object with properties id, name, and birthdate which we pass onto the view and attempt to output the birthdate with the following line:

echo date('Y-m-d', $person->birthdate);

This is going to cause an error. Why? Because the date function is expecting the second parameter to be a UNIX timestamp, but birthdate is already a formatted date string. Now, we could solve this by changing the schema of the database or changing the schema of the person object, but it is important to note that even if we did fix the disparity between the two we would still not fix the issue that it is possible for the person object to exist in an invalid state.

So my answer is to when should validation occur is during object instantiation and setting. The properties of the object should not be able to be set to a value that the object cannot accept. This places validation clearly into the realm of the “M” in “MVC.”

Form Validation in CodeIgniter

CodeIgniter’s documentation offers a form validation class that makes the above mistake very clearly. It can only validate the POST super global and doesn’t really offer much of a solution towards validation of objects themselves. Furthermore, their example controller oddly mixes the issue of object validation, and thus business logic, inside the controller which tends to create in many CI application fairly bloated controllers:

public function index()
{
  $this->load->helper(array('form', 'url'));
  $this->load->library('form_validation');

  $this->form_validation->set_rules('username', 'Username', 'callback_username_check');
  $this->form_validation->set_rules('password', 'Password', 'required');
  $this->form_validation->set_rules('passconf', 'Password Confirmation', 'required');
  $this->form_validation->set_rules('email', 'Email', 'required|is_unique[users.email]');

  if ($this->form_validation->run() == FALSE) {
    $this->load->view('myform');
  } else {
    $this->load->view('formsuccess');
  }
}

I cannot offer a solution towards adapting the validation class to be fully object operating without a heavy rewrite of the class, but we can move this obtuse validation into a distinct model that encapsulates this behavior away from the controller.

Introducing the Abstract Validator Class

We can get the validation logic out of the controller by moving it into a Validator class. We begin with an abstract base class since each form will need their own validator classes:

abstract class Validator extends CI_Model 
{ 
  protected $rules = array(); 
  protected $fields = array();

  # Get keys of fields.
  public function getStructure()
  {
    return array_keys( $this->fields );
  }

  # Validate $_POST against the rules and fields.
  public function validate()
  {
    foreach( $this->rules as $key => $rule )
    {
      $this->form_validation->set_rules( $key, $this->fields[$key], $rule );
    }

    return $this->form_validation->run( $this );
  }   
}

We take advantage of the fact that the CI god to access the form_validation object inside the Validator instance to create the validate method which merely sets the validation rules and then runs them. The Validator has two properties $rules and $fields which we will use in sub-classes to provide the CI_Validator rules and fields strings. We can transform the above controller into the following subclass:

class LoginValidator extends Validator
{
  protected $rules = array(
                       'username' => 'callback_username_check',
                       'password' => 'required',
                       'passconf' => 'required',
                       'email' => 'required|is_unique[users.email]');
  protected $fields = array(
                        'username' => 'User Name',
                        'password' => 'Password',
                        'passconf' => 'Password Confirmation',
                        'email' => 'E-Mail');

  public function username_check( $name )
  {
    return $this->users->check_username( $name );
  }
}

Here we can see how the rules and fields are used as well as how we can extend the Validator class to add additional unique callback validations. This simplifies the controller significantly:

public function index() { 
  $this->load->library('form_validation');
  $this->load->model('loginvalidator');

  if ( $this->loginvalidator->validate() ) {
    $this->load->view('myform');
  } else {
    $this->load->view('formsuccess');
  }
}

The business logic is now gone and the controller is back to focusing on what it’s supposed to be doing — load resources and running paths.


September 23, 2013

CodeIgniter’s God Complex

Filed under: Software Development — Tags: , , , — Joseph @ 9:00 am

Flattr this!

I have worked with Code Igniter almost exclusively for the last nine months. In that time, I have found it to be a massive step ahead over working with some of the major CMS systems on the market (WordPress, I am looking at you). Nevertheless, there remains some major architectural and blind spots that exist in CodeIgniter as a framework. Some of these issues are resolvable (CodeIgniter’s presumption that you would only ever want to validate the POST superglobal), while others are inherent in it’s design. In this series I hope to look at some of these issues that I have found with CodeIgniter, showcase work-arounds where I can, or simply rant where no good solution exists. Today’s topic will be of the latter variety.

The God Object AntiPattern

Lets dip over to WikiPedia for the definition of a God Object:

In object-oriented programming, a god object is an object that knows too much or does too much… a program’s overall functionality is coded into a single “all-knowing” object, which maintains most of the information about the entire program and provides most of the methods for manipulating this data. Because this object holds so much data and requires so many methods, its role in the program becomes god-like (all-encompassing). Instead of program objects communicating amongst themselves directly, the other objects within the program rely on the god object for most of their information and interaction.

The God Object in CodeIgniter

CodeIgniter started as an early MVC framework that has maintained backwards compatibility with PHP5.2. It’s maintainers have insisted on maintaining this compatibility which has limited CI from taking advantage the advances that PHP5.3, 5.4, and 5.5 introduced to the language.

There remains nothing truly wrong with PHP5.2. While 5.3+ offers us many great advantages, a SOLID framework is still possible using the older version. CI’s architectural issues do not stem necessarily from it’s usage of the older version but rather the violation of SOLID principles in archetyping it’s interpretation of MVC.

In CI we have the CI super class (the idea of a super class alone should be a code smell) that is globally available via the get_instance() function. This returns an instance of CI_Controller, our main application controller handling the current request. This instance is our elusive beast. The God Object itself. We’ll call this object CI from here on out.

In any one request there can be only one instance of CI — it is essentially a singleton responsible for:

  1. Loading models
  2. Processing the request
  3. Returning the response

Overloaded Models

Here is where we get into the meat and potatoes.

The CI object begins its life by loading resources, that is it begins by loading various models and libraries and maintaining links to each of them like so:

public function __construct()
{
  $this->load->model('news');
  $this->load->model('events');
}

This code instantiates an instance of the news model and assigns a reference to news. It then instantiates an instance of events. In this manner every model that comes into existence during request process is held as a reference by the CI object and can be access latter on in the request, e.g.

public function index()
{
  $data = array();
  $data['articles'] = $this->news->get( 3 );
  $this->load->view( 'news', $data );
}

Once more, something very peculiar is done during this process. CI not only instantiates an instance of the given model but it also copies these references to every subsequently loaded model.

Thus every object that is loaded in this manner becomes aware of every object that had been loaded up-to that point regardless of whether that object really needed access to the behaviors of those objects. The model becomes unnecessarily bloated and the difficulty of debugging the behaviors of a given model increases. Unintended behaviors might be caused not by the model itself but by the combination of that particular model and the order or selection of previously loaded models.

Examine a Model’s State? No way.

Take for example the simple act of using var_dump to see the state of an object in memory. If we were to var_dump our instance of news we might as well call it a day as news contains a reference to everything that has been loaded into memory for our request. The server will proceed to dump the entirety of our application to the screen for us to wade through!

No Public Property is Safe

A larger issue is the assigning of the references themselves. Since the first act of initiating the model object is to copy CI’s massive registry of references to the model any properties or references set in the model’s constructor is at the mercy of the controller overwriting the model. Take for example, the events model. Let’s say the following was in the constructor:

public function __construct()
{
  $this->news = new News();
}

Following substantiation of the events object the Events object CI will immediately overwrite the news property with it’s own instance of the news property. Thus the events model would either need to make the news property private or protected which would generate an error when CI attempts to access it or we would always need to take care to keep our model properties from existing in the same namespace as CI.

I actually ran into a horrible bug where this very thing happened. I had a class named Validator that I loaded in with the controller. I also intended each of my models to load their own instances of the Validator class and to initialize their instances with own unique validation parameters. However, since the controller had already loaded an instance of Validator it immediately overwrote each of my model’s Validator‘s forcing them all to use the same instance of the class. The resolution to this problem was to have to name each instance of Validator something different, thus we had EventValidator, NewsValidator, etc.




Copyright 2011 - 2017 Joseph Hallenbeck Powered by WordPress