Posts Tagged frameworks
Learning Web Frameworks: Expression Engine, Acquia Drupal, Ruby on Rails
Posted by fitzgeraldsteele in programming, python on October 5, 2009
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.
Conclusion
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.
