Ted Kulp

Silk is finally getting to that position where it’s about ready. All of the pieces that I’ve been putting together over the past few months are all starting to fall correctly into place and it’s getting usable.

I spent a lot of time over the last week working on the display portion of the system, mainly views, controller output, partials and javascript. Still a bunch of work to do, but I at least have results to work — now I can just refine.

Last night, I tested the concept of doing a very simple AJAX form, and it went better than I had hoped. Here’s the recap…

Create a controller. Being unoriginal, I called it TestController.php. It would go into the app/controllers directory. It would look something like:

use \silk\action\Controller;
use \silk\form\Form;

class TestController extends Controller
{
  function index()
  {
    $form = new Form('test_form', array('remote' => true));
    $fs = $form->addFieldSet('field_set', array('legend' => 'Config Options'));
    $fs->addField('TextBox', 'field1', array());
    $form->addButton('Submit', array('disable-with' => 'Submitting...'));

    if ($form->isPosted())
    {
      $form->fillFields();
      if (!endsWith($fs['field1']->value, 'was here'))
        $fs['field1']->value .= ' was here';
    }

    $this->set('form', $form);
  }
}

The 10,000 meter view is that we’re basically creating a form object. What makes it an ajax form is simply the 'remote' => true in the Form constructor.

Silk is using a style of javascript called UJS, which was made popular by Rails. Without going crazy w/ the details, the idea is that various hooks to the javascript can be created by simple HTML5 data-* tags embedded into the html. The remote basically adds a data-remote='true' to the form tag when output, and the UJS javascript takes it from there.

After that, we check to the see if the Form was submitted. If it was, we fill in the Form object with the values that were posted. Then, it’s just a simple check and append of “ was here” to the value that was input. Last, but not least, we set our form object to be visible to the views/template engine.

Next, create yourself a default view in app/views/test/index.html.tpl. The naming is important here. It’s basically saying that you want to have a view that a. responds to the index action, b. responds to only html requests, and c. is a Smarty template. It can very simply look like this:

{partial name="_form"}

This just renders a partial template called form in a div. This partial would be in app/views/test/_partial.tpl (it’s a Smarty template, and responds to all actions — html, js, etc) and would look something like:

{$form->render()}

Yup, that’s it. This takes the $form object set by the controller, and renders it to the browser with all of the form rendering defaults. Not fancy, but functional. Now, if you go to http://my.silk.vhost/test, you should get the form in all it’s glory.

However, if you fill in the text and hit submit, it won’t do anything. At least it won’t look like it, because the framework will call a 404. The reason is because the main view (index.html.tpl) is only looking for html requests, and since we set remote to true in our Form, it’s sending a AJAX=y ‘js’ request instead. Since the view doesn’t response to js requests that are beneath it, it says nothing is there and moves on.

In order to return back our updated form declaring that “value was here”, we need another view specifically for the js request. We would call that index.js.tpl, and it would look like the following:

$('#form_me').html({partial name="_form" js=true});

Again, yes, that’s it. We call our same partial, appending the js=true parameter. Behind the scenes, this runs the output through json_encode so that we don’t have to worry about improperly escaped values being sent back to the browser. The beauty here is that we’re using the same exact partial in the same exact way as the html version. The only difference is that we’re dynamically replacing the contents of the #form_me div w/ jQuery instead of refreshing the page.

When Color was announced a few weeks ago, there was very little talk about what it actually did and more about the fact that they got $41 million from Sequoia without anything being released. Most of the discussion was about how we’re in a bubble (which I still believe) and not about the actual technology.

Soon after the announcement, the app showed up in the respective app stores and then things got very interesting. Anyone that installed Color on day one was treated to an application with no instructions or clear direction of what it even did. It was confusing, almost cryptic, and people’s heads were spinning.

The only way you’d understand what it did in it’s 1.0 incarnation was to watch an interview or see a podcast discussing it or something else. Not exactly the best way to get your app to the masses — throw it out and confuse people. It received scathing reviews in the app store (one of which was absolutely hilarious by comparing it to an RPG) and tons of 1 star reviews.

It’s a typical engineer problem… it was too brilliant for it’s own good. If you opened the app anywhere but downtown or at a large gathering of other iPhone users, you saw nothing and it was just incredibly confusing. The problem, after it was explained, is it’s greatest feature.

Color creates an temporary social network with the other people running the app around you, totally on the fly. For example, two people are at a sporting event and both people start taking pictures. Color will figure out the locations of these two people and create a social network automatically in which you can see each other’s photos. Very cool… if you’re into that sort of thing.

If you’re a privacy freak, you’re probably jumping out of your skin right now. I’m not, but I totally understand where those people come from.

As an engineer, I think this is such a neat idea. It’s a great mashup of all the hot tehcnologies and making something that could almost be seen as magical. But the question that really needs to be asked if it really does anything for anyone.

Yes, it’s neat, but what’s the real purpose? When I was at the Sixer’s game last week and made an impromptu network with some guy named Tom, did it change my life? I’ll give you a hint… no.

It’s possible that I’m just not in the right demographic for this — I’m starting to think that’s the case for most “social” technology. But unless this is a gateway to some bigger and better thing, then I think I’ll just let it pass by and wait for the next big thing.

Hello,

The Silk Framework has been one of those incredibly difficult projects for me to work on. It's a project that keeps changing as my needs change and as technology (and specifically php) gets better. It seems that everyday, I think of something new or see something new that makes me want to take it in a slightly different direction in order to make it more robust.

The change to make it PHP 5.3 only marked a huge change that really allowed us to get creative and fix a lot of the things that drive me nuts about PHP programming. It's almost a real language now, and it gives me all kinds of great ideas. The fact of the matter is that the Silk Framework is going to be the base of a lot of really great things in the coming year, and because of this, I'm not afraid to change things around in order to make things clean and fast.

I started working on the reboot roughly two weeks ago. This consisted of copying all the existing code off to another branch, and clearing out master completely and essentially starting over by copying files one by one. Silk is basically back to the amount of functionality that it was at before, except in a lot of different ways.

---

What's changed code-wise:

* ORM

The custom DataMapper style ORM and PDO wrappers are gone. The ORM is now based on Doctrine2. While Doctrine isn't exactly what I wanted as far as "feel" of the ORM, it's fully featured and supports a ton of databases out of the gate, including MongoDB. I've written a Model wrapper around doctrine's functionality to make it feel more like a datamapper style ORM, but still keep Doctrine's power up on the forefront. In addition, I've also started work on an annotation based validator syntax, which ties in very nicely with everything else that Doctrine does.

* Naming conventions

I've moved from the underscore_naming_structure to camelCase style method naming instead. This is because all of the libraries we're using (doctrine, phpunit) already use this naming convention. It only makes sense to stick with it, as it's basically the PHP "standard", even if it's not my first choice. I've also redone the file naming convention so that directory and filename match the namespace and class name exactly. This makes the autoload logic very simple, which is a necessary thing when we want to easily include other libraries as extensions down the road.

I will put together a coding standards document in a bit that defines exactly how to format Silk code. As the gatekeeper to the project, I'll be enforcing that standard as much as possible -- so I'll make sure to use something common for most PHP projects.

* Rack

For those that don't know, Rack is a ruby library that acts as a standard wrapper library for ruby based frameworks. It makes a consistent request and response object and it also makes it possible to inject code and filters (called middleware) in before silk for very low level expandability. A good example as to how this works is the code for calculating execution time and memory used (see https://github.com/tedkulp/silk/blob/master/index.php and https://github.com/tedkulp/php-rack/blob/master/lib/rack/middleware/exec_time.php for a good example).

* Command line functionality

Silk is very much designed for being used on the command line and targeted towards Unix and Mac development and deployment. I've replaced the command line library with a very simple php based library called phake. It's designed to be very easy to add new commands to by just dropping .phake files into anywhere in the library or project directory. (see https://github.com/tedkulp/silk/blob/master/lib/silk/tasks/config.phake for a good example).

I'm also looking forward to making a fairly PEAR heavy workflow. Meaning that people can eventually just install silk via the pear command line tool, and have it available on their server without having to put the whole thing in git/svn for every project. Once we start getting closer to a real release, this will be something I'll look into.

* Testing

Silk will be using the PHPUnit tool for handling unit testing. As it's still "optional" (really, people, it shouldn't be), it relies on PHPUnit being installed separately via PEAR to be used. I would love for Silk to have high code coverage with it's tests, but that's definitely a lot of work and probably not likely for awhile yet. I personally have to get more into the mindset of making good unit tests and thinking in that way, but I still find it difficult to think of ways to make things "testable", so there's a lot to learn still.

* Pluggable template engines

While Smarty is still what I consider to be the main templating engine of Silk, it's not a requirement anymore. Out of the box, Silk also allows for PHP based templates, if that's your thing. Other templating engines can also be defined quickly via an extension and "just work" based on their file extension.

* Focus

Silk is going to be very specific on what it is and what it isn't. The framework is plumbing and nothing more. It will be things like: databases, ORM, caching, MVC, templating, forms, lightweight events and sessions. It will not be things like: users, groups, permissions, acls, module handling or any other high-level concepts. When you get to that point, everyone needs something a little different, and I believe it's beyond the focus of the project. There will most likely be semi-official extensions for handling some of these problems (I know I'll be making one), but they'll exist as separate projects and be started at a later date.

* Documentation

I'm looking at either using Markdown or reStructuredText for handling documentation going forward, using pandoc to process it. For the moment, however, we may just rely on the github wiki to handle some of the early text until we can get a proper book and documentation team together. I'll throw notes in there for the time being, and we can organize it a little better once the project gets some traction.

---

What's changed management-wise:

* Mailing List/Forums

I've removed the forums in place of a mailing list. The main reason is that the spam control and management that's required to manage a forum is too difficult to handle by myself at the moment. Since Silk is a developer tool anyway, a mailing list is a perfect communication medium for the types of people that will use the system at this point in it's lifespan. Maybe we'll bring back forums at a later date, but we'll see.

* Bug tracking

In order to simplify, I've removed mantis in favor of just using the standard bug tracking in Github. The project won't have enough bugs at this point to warrant a tool any more complicated that that, and it's easy to tie pull requests directly to filed bugs.

* Pivotal Tracker

I've been experimenting with using Pivotal Tracker for a majority of my projects. It's basically a story organization tool, and works great for laying out what "comes next". I haven't, however, used it with multiple users yet, so I don't really have a handle on how it would work with a project with a lot of different developers. That being said, I'm going to continue to experiment with it to see how it works for Silk. The Silk tracker (which has to be pruned for the reboot still) can be found here: https://www.pivotaltracker.com/projects/169369.

---

What's still missing?

* Form API

Not totally sure how to handle this one yet. There are several ways to approach Forms. My gut instinct tells me to define a form via a simple hash, so forms can easily be modified via events. The idea of a whole separate domain object/class for a form is also intriguing, but almost feels like overkill in a lot of situations.

* Caching

I didn't pull over any of the caching classes from the old version. I'd like to support simple key/value storage in APC, Memcache, XCache and the database. I would also like to tie in some things like smarty template caching, doctrine proxy caching, etc directly into that caching interface so that it can be configured universally.

* MongoDB support

Doctrine does support MongoDB, though it's technically a separate package/project. I personally feel that MongoDB is going to be the next big thing, and want to start using it some upcoming projects because of it's flexibility and scaling. Since it seems that SQL Doctrine and Mongo Doctrine have a very high overlap, I think we can just drop this type of support in. But, it's going to require a bit of testing to make sure it's just that simple. This is something that's on my very close radar.

* ORM Acts as/Behaviors

Doctine doesn't suppor the idea of acts as or behaviors. While the developers views on the subject make sense, I don't totally agree with it and feel that being able to add in behaviors to models is very important.  As part of the Model wrapper classes I did to give things a nicer feel, I'll add in the acts as stuff as well.  That should allow the nested set classes, list classes, etc to work again.

* Unit tests

There's still a ton to do here. I believe that Rack will make it easier to test some of the core components now, so this should become less of a chore. At a minimum, I'd like to at least test out the naming conventions of controllers, components and views, test template engines, and test request, response and session objects. Beyond that, it's not criticial, since Doctrine is heavily tested in it's own right (except for our additions to the Model object).

* Proper project generators

There's still no way to start a new project/site with the command line tools. We don't even have a proper config file generator yet (or even a sample config file). I'll commit a dummy one for the moment, but getting a tool to generate this stuff for a new project is kind of essential.  I'd also like to be able to generate models, controllers, views and tests via the command line tool. 

* Documentation

Enough said

---

If you'd like to contribute code or documentation, fork the project on Github, or modify the wiki as you see fit. Submit all patches through Pull Requests and I'll make sure to take a look and give feedback as needed.

Feel free to sign up on the mailing list (http://groups.google.com/group/silkframework) to discuss the project. I look forward to hearing some feedback and ideas. Things are still a bit premature yet and without good docs, it's going to make it tough for adoption. I'll do my best to start looking into getting some documentation going and hopefully help people wrap their heads around what I'm thinking as far as direction.

Thanks,

Ted