So I made the switch-a-roo and dumped MS Office of my system (safely archived on the original install CDs).
Above you see a sliver of the Terminal, Activity Monitor (‘cuz it’s neat), Coda, Numbers, Pages, and NeoOffice.
NeoOffice is there to do “heavy lifting” in case I run across some Office-y type function I can handle with Numbers or Pages. You know serious things like printing one mailing label in the middle of a sheet. You know. Hard core functionality.
I’ve also moved Abouthalf to WordPress.
WordPress has two big pluses over RapidWeaver.
- It’s not platform specific
- It imports and exports a variety of formats.
- One can edit a theme inline and on-the-fly
- It doesn’t bug me to upgrade every time I launch it
Four. Four big pluses.
I like the clean simplicity of the design, I like the placement of archives as links at the bottom and other features. I figure this was a nice palette cleanser while I figure out how I want Abouthalf to work in the future.
WordPress is a nice product for an end-user to work with. As a developer, I look at some of the plug-in code and shudder. WordPress is a very typical PHP application, and all that that implies. This is not relevant though. The blogging/writing interface is nice and clean, and I can export my data, or dig it out of my database however I want, meaning I can change my little mind any time I want.
Speaking of horrible PHP code, I’ve been working with the Zend Framework over the past few days, writing a ‘back office’ for a shopping cart.
It’s very nice. No really. It de-crappifies a lot of the problems with PHP application writing. The framework is PHP 5 only, which some my deride, I applaud.
The framework has a lot of the features that you mind find in Cake or Ruby On Rails. A Object-Relational-Data system, a controller object with view objects, a “Front Controller” class if you want to implement a full application.
I tried noodling around with CakePHP a few times. Went through the docs, tried the blog tutorial, tried it again. I always found it very counter-intuitive, and counter PHP.
One problem I find with CakePHP is that while it’s powerful, you can’t leverage any piece of the framework by itself easily. For example. Say you’ve got an existing web site…and you want to add on one simple data entry form. Cake wants you to build a whole app. While you hypothetically could extract its implementation of ActiveRecord, it wouldn’t be easy.
With Zend Framework you have the option of using only bits of the framework in a decoupled fashion.
So, for example, if your data-entry form only has one view, and one action, and it’s the only form you’re making, then you can just use the Zend_Db and Zend_Table classes and be done with it. If it gets slightly more complex, you could – at any time – add in a controller object – and then add in add in a view object when and if you need to. Nice.
In the past week I’ve found it to be easy to under stand and work with. The documentation on the individual components is pretty solid…however you may need to hunt for a good “putting it all together” tutorial. I’ve found two good ones by the same guy:
Coming soon I’ll detail how I used the Zend_View class in coordination with the Zend_Mail class to send notification emails from within a controller action method.