Learning Web Frameworks: Expression Engine, Acquia Drupal, Ruby on Rails

I work for a corporate website team.  When our internal ‘clients’ want a new web project — new page, contact or registration form, major page redesign, etc — they download, print, fill out, and mail us a paper form.  We recognized the waste involved with this paper form, and the irony that the website team does not have a web enabled project request form.  We do most of our work in base PHP, but we’re also evaluating various web toolsets/frameworks/CMSs to adopt for more of our projects going forward.  So we used this small form as a little case study.  Let’s implement this form in a number of different tools.  That way we get practical experience in these different technologies, and we can see first hand what attributes we’re looking for in a web framework.

Project Requirements

We met for a half-hour just to make our project requirements explicit.  We documented the requirements in a story map, and made a quick wireframe:

  • Client enters their contact details (name, department, phone, email)
    • Optional: Pull the contact details from the enterprise LDAP server
  • Client enters project details (name, description, budget code, deadline date, and whether the project has VP approval)
  • On submission, show confirmation page and email confirmation to client.  Also send email notification to our project managers that a new request has been made
  • Members of our team may view the list of projects (especially budget codes, which we need for our time sheets), and see project details
  • Project managers can add an estimate (number of hours we think the project will take), and estimate description
  • When the estimate is created, automatically email an estimate to the client

Now, to build it…

Expression Engine

I got the sense that Expression Engine started its life as a blogging only platform, and someone said, “hey…we could probably use this as a general purpose CMS too!”  I felt that if I wanted a blog or multi-blog site, EE would be great, but we clearly did not understand the “EE Way.”  EE does not come with a form builder out of the box, but we found the FreeForm module which got us on our way.  There’s no GUI form builder or admin panel; it requires a developer to build the form, which was a major downside for our team.  At the end of a 3 hour sprint, we had an expression engine form, styled how we wanted, submitting project requests and sending the project request emails to our managers, but not a confirmation to the client.  We didn’t get to any edit estimate functionality, and certainly didn’t have a way to email the client when the estimate was made.

We never really felt like we ‘got’ ExpressionEngine. It would definitely take a bit more time to figure out if this is the right tool for our CMS needs. The developers on our team felt like it would’ve been much simpler to just write the thing in plain-old PHP.

Verdict: With 4 people working for 3 hours, we got some minimal functionality, but we must be missing something.

Acquia Drupal

Ahh, Drupal.  Apparantly THE open source CMS.  Yet, to paraphrase Peter Parker’s uncle, with great power comes great complexity — and a steep learning curve.  Acquia is a batteries-included Drupal distribution, with optional paid technical support, which is attractive to our company.  Acquia includes the Webform module, which is a GUI, drag/drop form builder from inside the Drupal admin interface.  While the team was at lunch, I built the form by myself.  Furthermore, the Webform module provides a nice admin interface that allows for viewing all the results, updating entries, even downloading the submissions into a CSV file. One thing I really liked about the Webform module was that it comes with an area where you can post your own custom PHP code to be run after a submission…very cool.  Another nice feature was the conditional emails:  if the submission selects A, email to person A; selectB, email person B etc.

I had it in the default Acquia Marina template.  I don’t think we really get how to use Drupal’s templating system yet, so I’m not sure how we would apply our own custom styles/templates.  But I’m confident that we’ll be able to understand Druapl templating before Expression Engine internals (which is based on CodeIgniter — which by the way I really like as a web framework).

Verdict: The webform module is the bomb: 1 person, 15 minutes, done.  Not sure how to bend Drupal templates to make it look how we want, though.

Ruby on Rails

I’ve been looking for an opportunity to try a non-blog/wiki type rails app.  I checked out the Heads First Rails book from the local library, which taught me a lot.

It turns out Rails is tailor made for this type of job.  Rails scaffolding gives you an Apple-esque out of the box experience.  One command line basically got the full app functionality.  Given the name of the database model, and a list of field names and types, rails generates a database model, and the controller and view code for basic CRUD functionality:

ruby script/generate scaffold project first_name:string last_name:string email:string phone:string project_name:string project_description:text date_needed:date budget_code:integer vp_approval:boolean

Rails just really gives lots of tools to do the things you probably want to do on a web app. Need to add/change the database schema after the initial generate?  Migrations are your friend.  Send emails that get triggered on code events?  Use Active Mailer (ruby script/generate mailer) and you’re mostly done.  The views/templating/partials makes sense.  Scaffolding also gives you infrastructure for unit tests and acceptance tests (via the Cucumber behavior driven development framework).

So I was super excited about how quickly I could get something up and running.  I call over one of our graphic artists and one of our project managers to give them a demo of how to create, scaffold, migrate, and configure a rails app.  And I got mixed reactions.  Yes, scaffolding is impressive,  but you still have to be a bit of at techie/programmer to understand how to do it.  I think they were a bit intimidated by the command line knowledge required, as well as the need to learn a new programming language.  As I created a number of apps to show different parts of the generate/scaffolding script, the PM noted, “well, it looks like sometimes it’s easier just to build a whole new application rather than fix one.”  I thought that was insightful…she recognized that the auto-generated code makes it really ‘cheap’ to build a new application.

Verdict: Convention over configuration is great, as long as you can learn the conventions.  Once I started to learn the conventions, I could do a lot in a very little time.


At the risk of sounding cliché, you have to pick the right tool for the job, for your team.  For this single, stand-alone project, we’ll probably roll with the Rails app.  We can get that up and running super quickly.  I don’t know that we would ‘bet the farm’ for our entire site on Rails just yet, though.  Big learning curve for our department.  We’re really looking for a content management system.  We’ve got several instances of WordPress we use, so we’re used to that.  Personally, I’m leaning toward Drupal.  Yes, high learning curve, but it has a really flexible content model, lots of modules, an active developer community, support for workflow and fine-grained authentication/authorization.  And, with Acquia you have commercial support.

But of course the door is still open, and we’re looking at other toys to play with.  I’m going to try doing this form in Pylons, which looks heavily influenced by Ruby on Rails, with a couple advantages 1) written in python which I already know, 2) less opinionated about which tools you use at various points in the web stack.  It scaffolds a rest style controller, but not the views, models, or tests.


8 thoughts on “Learning Web Frameworks: Expression Engine, Acquia Drupal, Ruby on Rails

  1. Thanks for sharing your experience, I like this “real world” approach to comparing different tools.

    I’d be curious to know the final results *after you see each build approach to its end*. Drupal may have been quick out of the gates, but it might actually take 4 people + 3 hours each to “get” the templating system. And while EE does require a certain way of thinking, you may soon encounter an “ah-hah” moment, or discover that theming in EE is a breeze – even easier than WordPress I’d argue.

    Rails may win in the end, but you’d at least gain a more complete understanding of the tools at hand. A lot can happen in that last 20%…

  2. I think you have missed something but this could be more to do with the time constraints than your learning ability! It took me several months to grok EE but it’s been well worth it.

    Admittedly there could be more help for an absolute beginner but all you would need to do is build the form in HTML, add the Freeform tags top and bottom then make sure the names correspond with the form variables in Freeform.

    Yes you do need to build a thank you page but this is EE’s strength. You can point it back to itself and use a conditional to check for an additional URL segment or point to a whole new template.

    One thing to note is ExpressionEngine 2.0 will be built with CodeIgniter, itself a PHP framework, so you are free to build a form builder and release it as a module!

    If you need any help going forward then just Twitter to hashtag #ee or #expressionengine or jump on the EE forums. We’ll all be happy to help.

  3. Horses for courses of course. It sounds like you indeed missed what EE’s about but for the job you described why didn’t you look into CodeIgniter? It’s a lightweight PHP MVC framework from the same team that built EE. Its form validation and e-mail class are solid and easy to deploy.

    One thing I found odd in your article:”it requires a developer to build the form, which was a major downside for our team” yet you say your team works in “base PHP”… did I miss anything? I still have to meet the first client who could build his own form even with a so-called form builder.

  4. Wow! The EE community came out to represent their code! =) Thanks, guys, for the feedback and encouragement. It speaks highly of the EE community.

    @Erwin…I’m using CodeIgniter on a couple of other projects, so I’ve got some experience there. This project was about trying out some new toys.

    Let me try to clarify that statement. We’ve got a 7 person staff — all with some level of programming, but only 1 developer who’s full time job is to write server-side PHP/SQL code all day. I’m the UX Designer but I have lots of programming experience. While I can and occasionally do write some of the backend code, I try to focus on the front end.

    We get lots of project requests on the order of this form (event registration forms, sign ups, etc). As you might expect. The dev guy is pretty fully booked on other, bigger, longer term projects, so the work falls to others to put together when they can. So one of the goals of our CMS/framework search is to have a tool that can generate these simple forms quickly, reducing or eliminating the need to allocate someone’s time to write PHP/SQL.

    By scouring the interwebs for Freeform demos/examples, we finally did as @Hambo suggested. But it took a long time to get there. First, it was difficult for us to find useful Freeform docs. We found an example, but when it came time to customize for our form it was difficult to know what the freeform tags did exactly. Second, it took us a while to figure out that we had to create separate Freeform fields in a different place than the form template — the two seemed really far apart in the EE admin interface, and going back and forth in a trial/error manner wasn’t nice. Of course, there is a learning curve, but now I know how, and it still doesn’t seem that EE/Freeform provides the level of automated form building I was hoping for. Likewise, CodeIgniter would not help reduce the need for someone with PHP/SQL skills to build the form guts.

    Contrast this with Drupal’s Webform, which gives you a GUI for building your form — all the form building, customizing, and analysis options are available in one place. Rails was also strong in this area…

    Thanks for the discussion guys!

  5. Based on your requirements a small footprint framework like CodeIgniter or Rails would be my personal choice. ExpressionEngine is a great piece of software but it is not for everything. You hit the nail on the head when you said “you have to pick the right tool for the job.” Too many developers try to make WordPress or Drupal or ExpressionEngine (etc) work for every project they do. The reality is that you should learn various approaches so you can determine which is best.

    As Hambo mentioned you can throw tweets out there with hash tags for #ee or #expressionengine and get some help. The forums are also a pretty good place to bounce around ideas.

    Also just to clarify, EE 2.0 is powered by CodeIgniter but the 1.6.x branch is not. I also wanted to point out that CodeIgniter also has scaffolding built in. However, there’s nothing quite like a command line execution that creates models, controllers etc for you like Rails does 🙂

    It was nice reading your post. Best of luck on your continual learning of these tools!

  6. Pingback: Why use NoSQL instead of mySQL? « Fitzgerald Steele

  7. Just started my first project in EE 2 this week, 4 days in and I’m making progress – but it’s slow going. In terms of custom module development, there’s not a great deal of example code to learn from. Some of that stems from a smaller community (less documentation/tutorials) and some of it comes out of the commercialized software mindset that comes with EE (less of a commons). Having worked extensively with both drupal and django, EE in comparison doesn’t feel all that friendly to developing custom components. I really miss django’s auto-admin capabilities, CRUDing custom models in EE is very tedious. Learning new frameworks is stressful stuff, so I’m likely overly negative on EE being new to it – but I think rails and django are the two best games in town if you have developers on staff. Without developers on staff, I think drupal is the better option. I’d tend to agree with the post, once you’re past the core/built-in stuff and need to extend it, EE is tough to “get” compared to past frameworks I’ve worked with.

Comments are closed.