In my Beyond Frameworks talk, I explained how a component-based architecture can help answer some of the important (i.e. expensive!) questions you might face when creating long-lived apps that rely on a PHP framework. In this series of blog posts, I’m going to look at how to go about creating and working with components.

Components don’t exist entirely in isolation. They’re built to solve a specific problem, and ultimately to get used inside some sort of application (or two). To help explain one way to approach designing and building components, blog post by blog post I’m going to create a real app and its components, showing you the workings involved and highlighting any decisions that were made along the way. All the code will appear on GitHub, so that you can tinker with it yourself too.

If you want to jump right in and figure it all out in your own way by taking existing code apart, phix and the now-separated-out ComponentManager are both built as components in their own right. Clone the git repos, look at the phing targets in the build.xml files, and have a play. Poke me on Twitter if you have questions. If/when you run into issues, please file them on GitHub, and I’ll get them fixed for you.

Hopefully you’re staying with me for the worked example app though :) I’m going to start by defining what the final app needs to do.

App Requirements

I need an app that will consume a bunch of blog posts off the ‘net, and summarise for me how many are positive articles, and how many are negative articles. I’m going to use the data in future strategic planning sessions at work, to add another perspective where it will be useful. The app can be easily changed in future to analyse other data … I’m thinking of feeding it Flickr feeds too at some point, to give my photography some much-needed feedback.

Here’s how I’d summarise the technical requirements for this app:

  • The command-line portion of the app will do the analysis, running off a cron job.
  • The command-line portion will analyse a list of RSS feeds loaded from a .ini file.
  • The command-line portion will use a web-based API to score each blog article. The value of zero will be neutral; positive numbers mean the article is positive in tone, and negative numbers mean that the article is negative in tone.
  • The command-line portion will cache the results as XML files on disk (just to keep the example simple).
  • The website part of the app will present the analysis, consuming the summary data created by the cron job.
  • The app will be built as components, to make it easy to share code between both parts of the app.

That should give us enough variety to be able to get into some non-trivial examples.

With a very basic set of requirements documented, before I go near any code, my next step is to figure out a rough structure. I need to decompose my requirements into an architecture. That will be in the next blog post, which will along this evening.

Comments are closed.