Starting Simply with Solar

In an effort to get to know as much of the technology out there, I wanted to branch out in my framework knowledge and try something I hadn’t looked much into yet – the Solar framework (PHP5). I’ve worked with both the Zend Framework and CakePHP on previous sites, so I wanted to see how they compared. The Solar framework, worked up by Paul Jones and team, provides much of the same functionality as the other two frameworks and is even based around the same structure – Model/View/Controller – to get the job done.

Since there’s no time like the present and no better way to learn how to use a tool than to just jump right in and get started, I looked up the great Getting Started section of the Solar manual to get on my way. It’s a great little section jam-packed with all the info that you’ll need to get started. I do want to, however, go back over my experience with it all as another example of how I set it up and got it working for my little application.

First of, obviously, you’ll need the latest version of the framework on your machine to get started. Unzip it in a place outside of the document root for where you’ll be building your application. This makes it easier if there’s others developers on the box that want to use it later on. Then, when you update the library, you don’t have to do it in ten different locations.

First off, you’ll need to set up your configuration file – you can put this just about anywhere really, but outside the document root is suggested since it could contain username/password information for your application. My document root is: /home/website_htdocs/sampleApp and my config file, Solar.config.php is located in /home/website_htdocs. Here’s the contents:


//Base action href

//Base public directory href
‘adapter’ => ‘Solar_Sql_Adapter_Mysql’,
‘host’ => ‘localhost’,
‘user’ => ‘dbuser’,
‘pass’ => ‘dbpass’,
‘name’ => ‘sampleDB’

return $config;

The file is made up of the $config array with various values – among them the Solar_Uri_Action (the base action location) and the Solar_Uri_Public (the base for the public directory). That first option (Uri_Action) can be thought of the more “external” of the two. It tells the framework which URL the site will be using as a base. In my examples, I’m using mod_rewrite to handle the redirect of everything back down to the Front Controller (an index.php file that handles the routing), so I have it set to the root or “/”. Now, the Uri_Public setting is a little different story. This one is more “internal”, a setting that’s used to point the framework at the location of a public directory it can use to store things like CSS or Javascript files (and where anyone using Solar on the site) can use it too. I have it set to “/public” to point to a symlink that’s in my document root. Since Solar is installed to /home/website_htdocs/Solar, I made the link like this:

ln -s /home/website_htdocs/Solar/Solar/App/Public public

This points a symlink of “public” to the Public directory over in the Solar installation. This is handy for working with shared files and provides us a location so we’re not polluting the views and all with unneeded code.

With the config file and symlink in place, the next step is the Front Controller. This is a PHP file that Solar uses to define a few more things and start up the framework to handle the requests coming in. Here’s what mine looks like:





There’s two main things set here – the include path (to define where our Solar and application directories are) and the start() call with the path to the config file created earlier.

You notice the “sampleApp” in the examples above – that’s the name of the example application I’ve worked up. It’s nothing special, but it does follow with the structure they suggest for using Solar. To contain all of the files, we’ll make a SampleApp directory in the document root of our site with a few files and directories under it:


I know that looks like a lot of stuff, but most of those directories won’t even be touched. We’re only really worried about a few things. First off, let’s look what this all means. Each of the controllers have a PHP file in the App directory. In our case, we have a Base.php and Index.php file for those two controllers. Base is a special example that allows for cross-controller file use and communication. So for our example, the only thing in here is:

class SampleApp_App_Base extends Solar_Controller_Page {
// nothing really needed here, unless you want
// shared methods and properties too

This just makes the controller and extends the regular Solar controller. We’ll come back to the Base stuff in a second – for now, lets talk about the Index.php file:

class MySite_App_Index extends SampleApp_App_Base {

protected $_layout = ‘default’;
protected $_action_default = ‘index’;
protected $_view=”;
var $res;

public $output = ”;

function _setup(){
Solar::register(‘sql’, ‘Solar_Sql’);

public function actionIndex() {
$this->output = ‘this isdsds my example’;


This is where the action happens in our little application. The best part of it all is that, way back in the configuration file (remember Solar.config.php?) we set up a default controller to run when one’s not specified – “index”. That means that, when people just hit the domain (like http://www.foo.com versus http://www.foo.com/pageName) they’ll get what’s in our Index controller.

So, what is in there? Well, lets look at the different parts. Our class extends the Base class instead of the normal Solar_Controller_Page so that we can use the things in the Base directories without any other special code. Because of this, we can use the layout defined in $_layout. Layouts allow for things like site templates without having to add the header/footer to each of the views for all of the controllers. The value, “default” corresponds to a PHP file, default.php, that’s located in /App/Base/Layout. Here’s what it contains:


script(‘scripts/jquery/jquery.js’); ?>






This is pulled almost directly from their example with a few slight adjustments. One of the things that I wanted to do with my application was to use jQuery to handle some of the advanced Javascript. Because of this, I needed to include it in all of my pages. Naturally, in the layout is the perfect place. So I went to the jQuery site and grabbed the latest copy of their library. Now, remember that symlink we made a little while back – well, we’re going to go into that directory (you should see other directories inside it like scripts, images and styles) and inside of the scripts directory, make a jquery directory and put the file in there. That’ll match up with our example HTML, but you can always move it around to fit your needs. In our layout file above, you can see where it’s calling the script() function to grab that library and output an HTML tag for it.

The other missing piece to this puzzle is the view for the Index controller itself. The framework knows enough to apply the default template because of the value in $_layout, but it sill needs the value for layout_content to put in there. That’s why we need to make a view in /App/Index/View called index.php with the following content:

echo $this->escape($this->output);
echo “

"; print_r($this->res); echo "


You can match up the “output” and “res” properties from our actionIndex in the controller above. This is all packaged up and pushed into the layout and outputted. The script block at the bottom of the layout is just some Javascript using jQuery that adds a row to the table above it (I wanted a simple test to check if it was included and working correctly).

Finally, we get to the last piece of this mini application – the database connection. Now, you’ll remember way back in the config file, we defined some parameters:

‘adapter’ => ‘Solar_Sql_Adapter_Mysql’,
‘host’ => ‘localhost’,
‘user’ => ‘dbuser’,
‘pass’ => ‘dbpass’,
‘name’ => ‘sampleDB’

Aren’t you glad that this isn’t in the document root? So, these set the different values your script will need to access your database – in this case, a local MySQL one. Setting all of this up here frees you up to only have to work with the objects in your controller:


This example pulls the data from a test table named, creatively, test_tbl and pulls it into an array. This array is then pulled into the “res” property and added to the output of the view (as located in the View for Index).

So, there it is – that’s my experience so far with the Solar framework. It’s a little different than the other two frameworks, but I think so far, I like it a little more. It has a little lighter feel to it and doesn’t seem so much like someone dumped a toolbox over your head and told you to make sense of it all. Unfortunately, there’s still some of a learning curve to Solar. Once you get outside of the API docs on the site, there’s not a whole lot in the way of documentation. Thankfully, there’s always the guys in #solarphp on the Freenode IRC network to run to with questions.

Oh, and did I mention that the time from downloading the framework and getting all of this up and working was about 4-5 hours? Definitely works for me 🙂

Is your site Quiet?

Here’s an interesting article I came across (digg) today for all those working with content heavy sites – Andy Rutledge on “Quiet Design”. In it, he compares two major online news sources – CNN.com and USAToday.com – in things like layout, object placement and things they could do to help achieve Quiet Structure over Loud Structure.

It’s interesting to see his opinion that it’s not always about dropping content on a page to make things simpler but that it’s also about where things are on the page and how they’re laid out compared to the others.

A Primer to Using Air – Followup

Well, I poked around in the AIR documentation, and I think I found their preferred method (and the only method I tried that would let me grab data from another domain) of connecting to a backend script:

[cc lang=”javascript”]

function appLoad(){
var request = new air.URLRequest(‘http://www.php.net/news.rss’);
var loader = new air.URLLoader();
function completeHandler(event){
var loader2=event.target;



> ‘+v.childNodes[0].nodeValue+’



I think the code above’s a little flaky when it comes to inserting things back into the table, but the connection code is sound. It grabs the actual RSS file from php.net and pushed it into the table below it.

A Primer to Using AIR

Spurred on by some recent news and by the big push that Adobe is trying to make for PHP developers to get into Flex, I decided to try my hand at their newer (new to me anyway) offering, AIR the Adobe Integrated Runtime environment. The basic idea behind it is to allow web developers, without much more than the skills they already have, to make full desktop applications any user with the AIR runtime installed can use.

Thankfully, it’s pretty simple – once you wade through some of the documentation and find the section on creating a first application. Their example puts a div on a page and, when the application is started, pushes new content from a text file into that div. I opted for something a little bit more interesting and used something a little more handy than just regular Javascript – jQuery. There’s two choices for developers to go with – one for people already working with Flex and the other that I think most developers will follow, using HTML and Javascript (my path).

Construction of the application is surprisingly simple and consists of only three required files – a Javascript library they include in the SDK, the HTML file for the application to render and an XML configuration file to handle the application metadata. I wanted to do something more fun than their example, so I decided to go with a feed reader. It’s nothing big and it can only really real with RSS files (it should at least), but it is a pretty good example of how to get started.

First, we’ll look at the configuration file:

	My Simple Feed Reader

The XML Configuration File
The XML here is pretty simple but lets go through each line. The application container holds all of the settings for our simple app, both in the attributes and in the inner tags. The appId (capitalization is important here, as I found out later) parameter lets us give the application a unique name. In my case, I just gave it something simple that applied to the project. It doesn’t have to match up with anything else in the project. The next two parameters define the namespace and the version for the application. Inside of that, you can define a name for the application, something a bit more user-friendly and the look/feel of the app’s window (in rootContent – Note: for some reason the code highlighting plugin I’m using makes rootContent all lower case, but it needs to be mixed case for things to work). Ours just uses the standard “chrome” for whatever OS it’s on and defines the window as visible with a height/width of 400/200. Inside of the rootContent tag is the filename for the HTML file we’re linking this XML data to, the one that we’ll look at next:

	My Simple Feed Reader
		function appLoad(){
				type: "GET",
				url: "phpfeed.rss",
				dataType: 'xml',
				success: function(msg){
						$('#mytbdy').append('<tr><td>&gt; '+v.childNodes[0].nodeValue+'</td></tr>');
	body { font-family: verdana, arial, helvetica; }
	td { font-size: 10px; }
	#titlebar { 
		font-size: 15px; 
		font-weight: bold; 
		background-color: #6D66FF; 
		color: #FFFFFF; 
		padding: 3px;

	<div id="titlebar">FeedReader</div>
	<table cellpadding="2" cellspacing="0" border="0">
	<tbody id="mytbdy">

The HTML Document
This code is saved in feedReader.html and shows how to create the simple listing of titles from our RSS feed text file and print them to the application’s main window. This is where some of the real power of the AIR functionality comes into play. If you loaded this page up in a normal browser it would (almost) work perfectly. Web developers used to working with Javascript and HTML can pick this stuff up super-fast. I decided to use the jQuery library to help make things a little simpler (plus it’s one of my new toys coming from working with script.aculo.us/prototype and wanting something different).

Javascript & Parsing XML with jQuery
The Javascript uses jQuery’s Ajax functionality to pull in the file (no cross-domain requests so we’re limited to a local file) and run through it, parsing out the information in the title tags for each entry. In this example, the RSS is the feed pulled from the PHP.net website in the standard RSS format. jQuery uses a little XPath-ish magic and appends new table rows to the tbody of the table in the HTML below. The key to all of this, though, is in the body tag – the onLoad property. The AIR interface picks this up and executes our code automatically (inside of “appLoad”) so we don’t have to do a thing. Of course, in more advanced applications, you might not need this in favor of clickable items that fire off Javascript events.

Styling with CSS
Because the application is more or less a glorified HTML document, we can use CSS to style it. You’ll see that we styled things simply – the div up top to look like a header and some font styles and padding to make things look a little cleaner.

Building and Launching the Application
Having all the files is all well and good, but to make use of them we need two more steps – packaging the application and running it. Of course, you’ll need to have the AIR runtime installed to make the execution work, but you’ll also need the Adobe AIR SDK to compile the application into something usable.

Download the ZIP file and unpack it someplace useful so that we can get started. First, we’re going to test the application with a utility that’s a part of the SDK – adl:

/path/to/sdk_dir/bin/adl.exe /path/to/feedReader-app.xml

This will run the debugger against your code and error out if there’s an issue with the code. Unfortunately, in my experience, it only errors when there’s an application problem – not a problem with the code inside the app (like a Javascript error). There’s probably a way to turn this on, but I haven’t looked into it yet.

When that’s all well and good and passing tests with flying colors, we’re off to the last step of our little sample application – compiling the files into a package that can be shared and executed on any platform using the AIR runtime (you need to be in your project’s folder for this part to work without specifying paths for everything – it’s just simpler):

/path/to/sdk_dir/bin/adt.bat -package feedReader.air feedReader-app.xml feedReader.html AIRAliases.js jquery.js phpfeed.rss

If all goes well, you should end up with a neat little AIR package sitting in your directory that you can double click on and get the feedReader.air file in your working directory. Now, if you double click it, you’ll get this notification:

Click through to install it and you should now be able to run it with this as a result:

Wrapping it Up
Of course, this is by no means a complete tutorial on working with the AIR runtime – there’s tons more functionality and information out there on developing web-distributed desktop applications. Check out Adobe’s Adobe Labs section for AIR for lots of guides and other information.

I’m going to mess with things a bit more and see if I can figure out how to get the application talking to a PHP backend (that’s not on the local machine), so stay tuned for a second part to this tutorial. Oh, and please let me know if there’s anything in here that’s not working or doesn’t make too much sense – I know it’s a lot of information.

Book Review: The Design of Sites: Patterns for Creating Winning Web Sites (2nd Edition)

If you do anything on a website besides sitting in you chair only coding all day long, you owe it to yourself to check out a copy of this book from Prentice Hall – The Design of Sites. Now, I can almost feel the eyes rolling from here even at the mention of this kind of book, but trust me – pick up a copy and thumb through it and you’ll see the difference.

It’s not one of those “here’s what’s cool in web design right now” kinds of things. It goes a bit deeper than that and it looks more at the components and structure of a site rather than the things that you could slap onto the exterior to make your site a bit more trendy (Ajax revolution anyone?) Instead, it breaks things down into patterns that describe the bits that make a web site what it is.

Each of the patterns presented are components, like “order tracking and history” or “personalized content”, that can be swapped around and plugged together to make a site. Of course, a book full of these kinds of things could get messy, so they divided them up into chapters:

  • Site Genres
  • Creating a Navigation Framework
  • Creating a Powerful Homepage
  • Writing and Managing Content
  • Building Trust and Credibility
  • Basic E-Commerce
  • Advanced E-Commerce
  • Helping Customers Complete Tasks
  • Designing Effective Page Layouts
  • Making the Site Search Fast and Relevant
  • Making Navigation Easy
  • Speeding Up Your Site
  • The Mobile Web

It’s a long list of a lot of great stuff that could get hard to keep track of. Thankfully, they thought of this too and color-coded each of the sections. Then, inside of each, the design patterns all have their own shade of the color for where they fit. Using these colors (and a letter/number combination) , they reference the patterns beside some of the other related patterns. It’s a bit hard to describe without seeing it, so I’d recommend picking it up and flipping through it to check out the layout style alone (definitely well thought out).

All of the patterns are briefly covered in an overview chapter (to make finding what you’re looking for fast) and expanded out in the later chapters with descriptions, examples and screenshots. They don’t just describe the end result (like a “grid layout” or a “progress bar”) either. They explain the concept behind it and, if needed, get into a little design concept theory showing why the pattern would be used.

There’s tons of great stuff crammed into this book (weighing in at over 800 pages, not counting the Appendixes) – so much that I’ve really only scratched the surface of the content. Plus, for a book of its size, the cost is pretty good – $40 USD from a site like Amazon or Barnes and Noble.

So, “The Design of Sites: Patterns for Creating Winning Web Sites” – definitely pick it up and take a look. It’s nice to see a web development book that focuses more on making sites better rather than just making them better looking.

Oh, and a quick last note to the coders out there – don’t get this one thinking it’s going to be all about programming these patterns. It’s mostly a theory book with a dash of code thrown in here and there to show what they’re talking about.