New Pronto Snapshot: 20080428
I've been busy lately, but still steadily working on the ol' web framework. I'm starting to reorganize the core components to maintain a loose coupling between layers. Behold an incremental improvement! Huzzah!
I've been busy lately, but still steadily working on the ol' web framework. I'm starting to reorganize the core components to maintain a loose coupling between layers. Behold an incremental improvement! Huzzah!
In between my gazillion contracts and side projects, I've managed to eek out a little site for my latest toy, Pronto. Welcome to it!
2008 will mark my first year as an attendee at South by Southwest Interactive. So if you're around, look for the lanky guy with the Vaio and say Hi. I'll be hanging around the nerdy panels and the nuclear taco party.
Many PHP-based web applications use ISO-8859-1 as the character set, as this is pretty much the default in North America and Western Europe, as I understand it. The problem is that this doesn't work out so well down the road if you intend to internationalize your web application. What if someone wants to write a blog comment in Greek, or drop a little Chinese in there? You'll probably end up with a bunch of weird diamond-shaped blocks or odd-looking question marks, depending on your browser.
Nowadays everybody is pretty much in agreement that UTF-8 seems to be the way to go. It's backwards-compatible with 7-bit ASCII and it can handle all the other character encodings out there, so you don't have to juggle them all anymore. So with the choice of ultimate charset out of the way, it's just a matter of convincing your RDBMS and scripting language to agree on the same charset.
So in our past episodes, we covered the basics of page controllers and data models, so it's probably time to go over templates.
Templates are pretty basic -- they don't vary much from framework to framework, except for the choice of template language: native PHP or a third-party markup such as Smarty?
My choice is native PHP. I see no reason to introduce another layer of abstraction when proper PHP is just as easy to read or write. The plus side is you get to avoid the performance detriments (and extra caching layers used as workarounds) of parsing another type of markup. If you look at something like Smarty, all it's really doing is parsing your template code for Smarty tags and converting them to native PHP. Why not skip that step?
If you're into theoretical physics (at the armchair level) and string theory, then this 12-minute video is a must. Thanks Hapy!
Here's an example of Pronto in real-world use. Though most uses of Pronto at present are for client websites, TipCache was a personal site of mine that I whipped up one afternoon last Spring.
It's about the quickest site one could write while still calling it "dynamic" -- it has two basic entities, users and tips. The whole function of the site is to provide an easily-searchable database of quick, one-off tips and howtos related to IT.
Since Ruby on Rails first came out, many frameworks have adopted its ActiveRecord data modeling system. I've never used Rails, but I did spend some time with CakePHP, which has a similar ORM scheme.
I realize the potential power of such a model, but its never really done me any favours. And since it's my party, I've left out any complicated ORM stuff from Pronto. We have data models, but they are relatively dumb compared to some of the ORM stuff I've seen in other frameworks.
Why? Personally, I believe typical SQL isn't very hard to write, so I craft it manually for each and every data model I have in a project. I find this just as easy (and sometimes easier) than trying to define all the inter-entity relations in some weird format. Writing a SQL join is usually fast and easy, and if I lay out my data models correctly, I only have to do it once per relation, then I just call the proper methods in my data models and I have the same functionality as I would with a more dynamic ORM approach.
Website designs tend to get a bit stale, especially if you stare at them a lot. Here is this year's incarnation of Zeroflux.
When we left off last time, I was giving a nice contrived little example that illustrated how Pronto tries to eliminate redundant code while providing rich widgets and standard data entity operations.
Now we're going to jump back a bit and talk about some fundamentals. Now I should warn you -- the fundamentals are the building blocks of the framework and so I may digress from time to time in an effort to explain my reasoning behind the design decisions I made. Bear with me...