I had started out building a new php project to have blocks of html code within class files that would do find and replace on the html, adding dynamic code where I had written special tags. Essentially, I had templates and PHP logic that powered them. In the course of researching something for this, I came across Smarty Templates. I’ve switched over to using this system to power the interaction between templates and logic on this project and I think I’ll be using it more in the future. It’s pretty dope. Fundamentally it defines special tags you instert into html and has a special class with methods designed to populate these tags. Here’s a little overview of some of the reasons I’ve decided to use them:

Reasons for Smarty:

• Compiling of templates so that str_replace lag is removed (read: speed)
• Caching of pages. This would be a way to reduce the amount of queries that are run (read: speed)
• Full seperation between logic and code. The logic could be only in the engine while the templates follow the master, theme, client route.
• Should allow custom templates to be a lot easier to make for noobs and may actually encourage more customization
• Was created in like 2002 and continues to be updated even in the last week
• Works in conjunction with popular php accelerators
• Developed in part by php team

Some links I was looking at while researching it:

• http://smarty.php.net
• http://www.onlamp.com/pub/a/php/2002/09/05/smarty.html
• http://www.sitepoint.com/article/smarty-php-template-engine

Anyway, it’s a cool system.

I installed Leopard on my work comp last night. Because I was scarred of php/mysql config from Mark’s post I ended up using Mamp. Just learned of it this morning and installed it, but it’s working pretty nice. One useful thing is it makes it really easy to change your apache directory, so you could test sites out as the root of the webserver without any host file / vhost shenanigans. Also, you can quickly switch between php 4 and 5. I wish it installed as a system pref instead of an app, but still, pretty rad.

I’m boning up on architecture design while I get ready for a big community site we’re making. I learned some new things about MySQL this morning (reading Ben’s “High Performance MySQL” book I thought would be useful to share:

• MySQL will only ever use one index per table per query. Therefore if you have a query that has multiple columns it’s matching in it’s where statement, it only matters that one of them is indexed. And, if I’m correct, you’re better off having the column with the most diversity indexed.
• This sort of follows from the previous, but this where multi column indexes come in handy. To use the book’s example, if you are always SELECTing based on last name and first name, if they are each separate indexes only one will be used. Thus, to fully optimize that SELECT, you’d want to have a multicolumn index over both of them
• If you’re using a UNIQUE column just as a way to not allow duplicate entries in a table, it adds overhead. You may be better of checking for duplicates in your application before INSERTing. This may be an occasion to use InnoDB’s transactions too.

I’ve been running Leopard on my laptop for the past week (haven’t put it on my work comp yet) and there is a lot I like, but as usual, there are a number of irritants. One on that list I’ve been able to put to bed. The finder behaves unexpectedly when used with spaces. Or rather, it behaves like it should, but it just feels weird. To be able to manage the finder absolutely, in my case making it available in all spaces, you just need to know where to look for it.