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