Posted 07.24.2010

Posted 07.24.2010

CodeIgniter and Understanding MVC

I’ve been working on a super secret side project. I’ve been build it out with Code Igniter. which I absolutely love. I’ve mentioned before how much I love Expression Engine. Well, Code Igniter comes from the same company, Ellis Labs. The first time I “got” Code Igniter, I totally geeked out and literally started giggling.

People will ask me how I’ve taught myself to program. Code Igniter was a little different. I started digging around online and found a few articles. By piecing them all together, I was able to create a better whole. One of the reasons I love Code Igniter is because the documentation is so well written. However, I needed a resource to get me jump started, to give me a starting place. So, I thought I would share some of the things that I’ve learned. Hopefully this will mean one less Google for you (because you’ll find what you need here.)


Wrapping your head around Model-View-Controller (MVC)

This was the hardest part for me. Once I understood MVC, everything else fell into place quickly.

In programming, there are several different patterns for building and organizing that are supposed to make things easier, not only for you, but anyone else reading your code.

The idea behind MVC is to separate all the layers of code. Your database calls, one layer (model), what the user sees, another layer (view), and a layer that talks to everybody (controller). This is great because it means that presentation and design is separate from you database. Why is so great? A few reasons.

  • Design is separate from your code. Meaning, if someone has to make changes, they won’t mess up your database.
  • Or, my personal favorite reason, it’s so easy to reuse code. Smarter, not harder. Write it once, in one place, and be done with it.

Let’s dig a little deeper.

MVC Diagram


Model

As I mentioned earlier, the model is the layer that talks to the database. It makes all your MySQL calls and returns what it finds.

Generally, each table in the database should have it’s own model. (Obviously, there exceptions.—I don’t have models for relationship tables)

Ellis labs has created some naming conventions. For models, all files are appended with _model.php This may seem fairly obvious, but just for kicks and giggles, if I had a comments table and a blog posts table, I would have 2 models: comments_model.php and blogposts_model.php


View

Even though the view doesn’t talk to the user directly, it has the pieces the user actually sees.

For example, if you have a standard HTML page, I’ll usually divide it into 4 different files. — Think about how you would set up php includes.

View Pieces

I split the page header and the top of the page into two different files. Why? Because, sometimes I’ll have JavaScript or CSS files unique to a given page and want to be able to insert those into the header. For example, a Contact page might have form validation on it, but the about page definitely doesn’t need that information.

Now, if I have to make changes to the navigation or something in the footer, I only have to do it in one place. Smarter, not harder.

As I hinted in the diagram above, all view files are prepended with _view.php.

Before, you get mad at Ellis Labs for making decisions for you concerning file naming, it actually is quite beneficial. It helps me keep track of where I’m at in my code. If I’m creating a comments section for my blog, I’ll have a comments_model.php and a comments_view.php. Granted, they stay in separate folders, but I can easily tell by the file name what its purpose is.


Controller

This is the piece that does all the work. It asks the database a question, passes the answer to the view, and shows the user.

The file name for the controller is just its name. It’s not appended with _controller.php. Continuing with my blog analogy, the filename would simply be blog.php.

The controller name is actually part of the URL. For my blog.php? it would be index.php/blog or for an about page that was controlled by about.php, it would be called index.php/about

Note:

You can create a mod rewrite to control your URLS so the user doesn’t have to see the index.php part.


Earlier I mentioned other articles that I had found online. If you want to do some more reading, here are a few places to get started:

 



Posted 07.18.2010

Posted 07.18.2010

Web Analytics = Fail

I’ve been challenging myself to read through the personal MBA. For those unfamiliar, a few people that got their MBA at Harvard, decided that the same education (if not better) could be achieved by reading a number of books. (and by number, I think it’s currently 96!)

Web Analytics: An Hour A Day
One of the books on the list is Web Analytics: An Hour a Day. So far, for a book about numbers and statistics, it’s proved very readable. grin

The introduction alone has me reconsidering how we view analytics. I told you the other week, that we had declared a blog war in my office. So far, we’ve only used hits and page views to measure success, but according to this book, that should be questionable.


PAGE VIEWS

A page view is generally the number of pages a user will visit when they go to your site.

If you run an e-commerce site (or any other site for that matter) and the user can’t find what they’re looking, naturally you’re page view count will increase as they’re clicking around, trying to find what they’re looking for.

On the other hand, they could find what they’re looking for immediately, but the price is better somewhere. They leave.

Which is the case? A page view count will tell you neither.


Hits

Way back in the way back, hits tracked how many requests the server received for data. Then, a request for data should translate into a page visit, right? More hits = more visitors. Well, what if there are images and media embedded on the page? Then, a typical page will cause 25 hits on the server. Excuse me? What are we tracking? requests for data? number of page views? number of visitors?


Top Exit Pages

An exit page is the last page that a user looks at before leaving your site. What does that information tell you? Those are bad pages? or that the user simply found what they were looking for? The exit rate doesn’t tell you good or bad.

This is only chapter 1!  —Should be good a read. If you’re interested, here’s the book’s website or the author’s blog.

 



Posted 07.13.2010

Posted 07.13.2010

The Perfect Workflow for Building a Site

A year and a half ago, I worked for a company called echo (formerly echo music). My job title? Site operations. I sliced and diced sites for artists and entertainers (yeah, it’s fun to name drop in conversations). I quickly learned the value of workflow, giving yourself a starting place. —not only does it remove the mundane, but if time is money, you’re saving yourself some!

If that’s not convincing enough, it makes a world of difference in a collaborative environment. It means any project I work on, whether I started it or not, I know where to look for the files. Everything is organized the same way. —Stink! Even if you’re working by yourself, it still makes a huge difference a year down the road. Everything is consistent and organized.

—All that’s to say, I thought I’d share what system has worked for me.


Folder Structure

I keep my template folder on Dropbox. — that way, whether I’m at the office or at home working on a freelance project, I have the most updated templates with me.


I have a folder named !!FOLDER_STRUCTURE The double exclamation points mean that the folder appears at the top of the list. Inside, I have 6 more folders. (I’ll list them in the order that I use them.)

RAW
This folder contains any media, images, or marketing pieces that a client gives me.

DOCS
I have two subfolders inside: FROMME and FROMCLIENT I keep any documentation, contracts, creative briefs, site copy, etc in here.

COMPS
This folder contains all the design comps.

I use the Google Blueprint CSS framework. So, in this folder, I keep a blank psd template that already has my guides for Blueprint set up.

My naming system is real creative (COMP_1.psd, COMP_2.psd, etc.) Any options or variations to a comp? I append an _O1 or _O2, option 1 or option 2 respectively. If I send a file to the client and they kick it back with revisions, I append an _R1 or _R2, revision 1 or revision 2.  By the end of a project, I could easily have a COMP_3_O2_R2_O1.psd. The nice thing? It’s easy to tell, at a glance, which file is the most recent.

BUILDS
Once I start the production work on a site, I keep any files that I use to build the site here. So, if I start slicing a psd, I’ll save the psd as a separate file inside this folder instead of overwriting the one in the COMP folder. Back in the day? Image maps and pngs lived here.

FLASH
This folder is getting used less and less (Thanks HTML5, CSS3, and jQuery!) This folder is similar to the builds folder, except it holds only Flash files.

PRODUCTION This folder contains the actual site code. Let me break down this folder a little more…


Production Folder = Site Template


CSS folder

As I mentioned earlier, I use Google Blueprint. I LOVE it. What changed the game for me was the first time I opened IE6 and didn’t have to hack any of my code to make it work. I said, “Done and done.”

My CSS folder has 4 files to start off, 3 of the 4 are from Google Blueprint

  • ie.css Stylesheet for Internet Explorer
  • print.css Printer style sheet
  • screen.css Screen style sheet (includes a reset)
  • SITE_NAME.css This is my style sheet. One of the first things I’ll do when i start a new site is rename this file to the name of the site.

    Inside the file, I already have basic formatting styles set up here. For example, all my sites have a class called .left which will float an item left. (surprised?) or a .thumb class which will add a 5 pixel margin to the right and bottom of any image. Don’t make yourself reinvent the wheel! Smarter not harder!


images folder

This folder has only one file, spacer.gif Some may argue its old school, but it’s my security blanket. I’ll pull it out every once in a while, for better or worse.


js folder

I keep all my javascript files here. By default there’s

  • jQuery This seems like a given
  • SITE_NAME.js like SITE_NAME.css, one of the first things I’ll do when I start a site is rename this file to match the site. This is great for storing jQuery functions that I know I’ll need to call on every page.
  • swffit.js and swfobject.js I don’t load these automatically, but like to keep these files close. I’ll pull these out anytime I use Flash on a page. They definitely make your site degrade nicely.


SWF folder

Any .swfs I use on the site, I’ll keep in this folder. This folder is getting used less and less.


XML folder

Any .xml files live here. Again, this was used more when I was creating Flash navigations.  So long fair well?


crossdomain.xml

Another file that helped with Flash…


index.html

The code inside basically links everything together. When I start a site, I simply change the file name for SITE_NAME.js and SITE_NAME.css to match the name of the site.


DOWNLOAD

Feel free to download my folder structure and use it as your wish.


What other tips do you suggest?