Symfony2 – first impressions

Posted on October 19, 2011 by jesse

I didn’t want to spend my summer programming in my free time, so I didn’t. There were a few sunday mornings where I poked around with Symfony2 over a cup of coffee, but I wasn’t quite determined to build an application with it. I’ve been planning to build something with Symfony2 for some time, and now I am.

First off – I’m experienced with ZendFramework and ORM’s. I’ve done a lot with ZendFramework, and I’m very comfortable with it. I’m aware of some major differences between ZendFramework and Symfony2. If you do a little research, you’ll find what I’m referring to.

Anyways, I’ve spent the better part of the last few days with Symfony2, and here are a few things that stood out right away:

  • clearing cache with the console tool: I ended up using `sudo rm -rf app/cache/*` because permissions are a mixture of being owned by Apache and my development username. The tool needs to create folders: prod, prod_old, prod_new, dev, dev_old, .. What is the correct way to do it??!! I don’t know.. and I wasn’t able to find any search results that provide a good example of how to deal with this. The console tool was not working as intended. In some cases I was able to clear the cache with the console tool, after running it 3 times.
  • creating model entities with relationships: for example, try creating entities ‘post’ and ‘category’, where ‘category’ is a parent to ‘post’. This task should be simple for someone who knows exactly what to do. Sure, practice makes perfect.. I’ve done this many times using ZendFramework and an ORM, but it took some tinkering here. What is the correct order to modify entities? I’m using yaml-based schema files rather than annotations in my Entity classes.. I ended up editing my Entity/Model files before the Symfony console would accept my schema file changes. It seems I have a little more to learn here, but the console tool did not do what I was expecting. I was expecting something similar to generating and re-generating model classes with Propel 1.6, where you basically just edit the schema, then run a command from console, and it doesn’t ‘complain’.
  • Generating crud from the console tool frequently errored out when creating routes. This is the last step of the multi-step dialog in the console tool, when creating crud based on an entity. Generating entities seems to recognize pre-existing functions, so I wonder why it cannot recognize pre-existing routes, and append new routes.
  • I ended up adding __toString() to my entity classes, after some research; in order for my forms to render. It’d be nice if Symfony2 left a comment or something somewhere that brought attention to the need for this.
  • It’d be nice if Symfony had an in-depth tutorial/walk-through that included some variety between parent/child relationships and integer/string keys in the database.

I’m still very interested in learning about Symfony2 development, including the ‘gotchas’. I’m just a little surprised at this point, that some aspects are not as simple or easy-going as I’ve experienced with ZendFramework and Propel 1.6.

Posted in Uncategorized | 1 Comment

How ZForms works

Posted on January 3, 2011 by jesse

ZForms can do a lot of stuff. I’ll try and describe what’s under the hood in the simplest way I can.

The general idea is to have a page or post for each step of a form, as well as a confirmation page. For example, a single step form would need two posts: one for the form and one for the ‘thank you’ page or confirmation.

If you edit a step within ZForms, you’ll see a dropdown box for the ‘Next Step’. This is where you’ll choose which post or page contains the next step of the form, even if there isn’t a form eg a confirmation page. You will want to have a unique set of posts to work with, so that the user doesn’t end up at the same post they started at. When you create a form, you’ll probably already know how many steps there will be, so I would just create the posts (if needed) right away and add the shortcode to each of them. Now, when you create your form steps, you will have the posts you’d like to use available in the dropdown box right away.

Once you have a form key created along with a step or two, you can create inputs. The most common inputs are available, except ‘File’ input is not implemented yet. (It’s on the way btw.) After you’ve added at least a single input to each step of the form, you should be able to see the forms show up on your post.

After you’ve added inputs, you can look at adding validators. Maybe you’re expecting all numbers for an input, or maybe you’re expecting all letters for an input. This area will be growing more soon within the plugin.

As people submit forms, the plugin will ‘catch’ the submission and either redirect back to the invalid form, or redirect to the next step..

I’ll blog more about details. I should probably make a tutorial with screen shots. Hopefully this helps for now.

Posted in Uncategorized | Leave a comment

ZForms 1.0 is ready !

Posted on January 2, 2011 by jesse

Download ZForms

Be aware that this plugin requires another plugin to load Zend Framework. It also adds about 10 tables to the database. I realize this goes against the grain of using WP’s api, but I chose to use Zend Framework’s api instead, and part of it requires having tables with primary keys. I think this will help shed some light on how ZF and WP can work together.

This should be a valuable tool for anyone who is interested in learning about Zend Framework and WordPress plugins.

Posted in Uncategorized | Leave a comment

MVC-based WordPress plugins

Posted on January 2, 2011 by jesse

A majority of WP plugins store all of the functionality in two or three files. While this works fine for simple options and posts, it is possible to structure the plugin in a way that resembles the Model-View-Controller design pattern. When using MVC with larger plugins, the amount of code that is loaded will be much less compared to having everything in two or three files. The weight of the plugin will change less as functionality is added to the plugin. This is another reason to structure your WP plugin code in an MVC fashion.

Most WP users have heard of ‘Hello Dolly’, the single file plugin that we all look at when we decide we’re going to learn about WP plugins. The first thing we learn is that we can do a lot with a single file. The next thing we learn is that WP is procedural and uses a defined set of events that can be hooked into from anywhere within WP’s load process. From an MVC perspective, this is where the styles need to be adapted to each other. A good solution is to designate a script to serve as the plugin controller. With MVC, we’re going to separate our objects into modules and actions, which should keep the plugin lightweight regardless of how large our plugin application becomes. Although, at a certain level, this may be overkill for some smaller plugins.

Ok, so let’s use an example to illustrate this concept. Let’s say you want to store food information. We want to be able to separate the vegetables from the fruit, so we need food categories as well as food items. We will need to be able to add and edit everything as needed, so we’re looking at implementing CRUD (create/retrieve/update/delete). This means we’re looking at separating our two modules (categories and items) into actions, similar to MVC controller actions. Many apps use: add, edit, update, trash, and list as the action names, so that’s what we’ll use for this example. From here, we know what most of our file structure will look like.

As far as the plugin settings, you could do that like most plugins do, and basically have a single file for handling it all. This isn’t illustrated in the image.

We want my-plugin.php to load my-controller.php as the main script. What goes into my-controller.php ? 

$module = $_GET['my_module'];
$action = $_GET['my_action']; //careful with WP's url vars
$defaultModule = 'categories';
$defaultAction = 'list';
$moduleActions = array(
    'categories' => array('add','edit','update','trash','list'),
    'items' => array('add','edit','update','trash','list'),
);
if (!isset($moduleActions[$module])) {
    $module = $defaultModule;
}
$actions = $moduleActions[$module];
if (!in_array($action, $actions)) {
    $action = $defaultAction;
}
include "modules/{$module}/{$action}.inc.php";

This is the simplest way to illustrate what it would look like. Basically, you’re getting two strings from the url and including a single file. The goal is to load code for a single action by referencing the module and its action. Also, by pre-defining the action files that exist in your plugin with an array, you can control access to the plugin files. If someone is messing with the url string, they will get the default module and action. You would probably want to filter request parameters also. Any changes you make here will affect most of the plugin functionality, as this is the main code that the my-plugin.php file includes in WordPress admin.

What goes into an edit.inc.php file?

if (!empty($_POST)) {
    $formData = $_POST; //should sanitize
    //save submission to database
    include("list.inc.php"); //cannot redirect to listing
} else if (!empty($_GET['row_id'])) {
    $rowId = $_GET['row_id'];
    //load row data into form, and display form
    include("helper/form.inc.php");
    $form = helper::getForm($rowId, $populate);
    echo $form;
} else {
    //we didn't get the row Id, so show the listing again
    include("list.inc.php");
}

There are some blanks to fill in this code example, but it should look similar to most form handlers. Basically, you’re either displaying the form or handling the form being submitted. You can leave the form action blank for this, so it submits to itself. You could add an extra step in the form handler to validate the form and re-display it with the validation errors if the submission doesn’t validate. Also, I recommend using a common getter method for retrieving and populating the form like the helper/form.inc.php file in the image and the helper::getForm() method in the code example.

Hopefully this provides a simple example of how WordPress plugins can resemble MVC. If you’d like to explore this concept further, you could download my plugin, ZForms, and look at the code. I include Zend Framework code in the plugin, so it can serve as an introduction to Zend Framework also.

Posted in Uncategorized | Leave a comment

ZForms Plugin

Posted on November 12, 2010 by jesse

I started coding a WP plugin a few weeks ago. I’m naming it ZForms, short for Zend Forms. I really like the form interface in Zend Framework. Besides having elegant and modular functions for creating and validating forms, it is friendly to creating forms programmatically.. This is the idea behind the ZForms plugin.

As a web application developer, I’ve worked with a list of content management systems and web application frameworks. This plugin brings together some ideas and concepts that I’ve chosen as being powerful and effective. I’m hoping ZForms will bring useful and valuable tools to WordPress.

Posted in Uncategorized | Comments Off