Silk Framework Reboot
Ted Kulp
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