The most recent one was as to why the shorter urls ie: “/index/pants” would not work.  It would always complain and blow up that the controller ‘pants’ doesn’t exist.  Even though I know for a fact that I want the index controller in the default module and the action ‘pants’…

The problem with naming your default, or any module ‘index’ is the way ZF matches and routes the request.  If you have a module called ‘index’ then any request that begins with ‘/index’ will get routed to it.  Even if this isn’t what you want.  Typically  when I have actions like ‘about’ or ‘contact’, they reside in my default module and are easily accessed by ‘/index/about’ or ‘/index/contact’ – when a module exists called ‘index’ these shorter links don’t work and I’d need ‘/index/index/about’ or ‘/index/index/contact’ – these suck and thus you should never have ‘index’ as a module name.

The point: If your default module has to be in the URL to access these default actions, you’re not using the ‘default’ module properly.

At some point I’ll probably put it on a public SVN repository, but for now you can have the tarball.  There’s a README in the file with a simple sample. And the source is pretty self explanatory so you should be able to figure it out if you want to.

The remainder of the work will be done in the order I see fit.  Likely read-only methods (most of the getters) Authentication and write methods will be much much later.

I’ll also add more RESTful interfaces as I need them.  Probably Facebook soon, Twitter later.  Who knows.

Drop your comments here if you’ve got any questions.

Over the last year I had been using a Java Bridge from a Zend Framework application to access a Java only API.  And really, between the two bridges there are no differences.  They both work identical, they both work great.  Would I pay Zend for Zend Platform’s Enterprise license? No.  Why? Because both bridges perform the same.  The only differences are:

1. Zend’s Java bridge already has a function called java_require and the open source PHP/Java Bridge needs you to include a file.
2. PHP/Java Bridge has a java_cast function, and you need it.  Zend’s Java Bridge does not have, or need this.

With these two differences all you need is a little code in your bootstrap (or somewhere else useful) to cover them and all is golden. Your app should work with both Java Bridges without any issue.

/* no java_require() include the java.inc for PHP/Java Bridge */
if ( ! function_exists('java_require') ) {
    include "java/Java.inc";
}

/* declare this, it doesn't exist with Zend Java, but is needed for PHP/Java Bridge */
if ( ! function_exists('java_cast')) {
    function java_cast($whatever) {
        return $whatever;
    }
}

There’s probably a more graceful way of checking and doing this but that’s it, and it’s worked on a multi tiered build environment for over a year now.

There’s a good listing of what’s new over here and really on the surface it doesn’t look like much. But as a person who’s been using ZF for quite some time, I’m really happy to see some integrated tools for creating the application structure in a quick and easy way. As long as module creation support makes it in for 1.8, things will be great.

Aside from that, I’ll be interested in seeing what Zend_Navigation has to offer.  Seeing as I’ve had numerous instances with global navigation, crumbs, module based navigation and I’ve had to create something each time – a single one-stop-shop for nav items could prove to be very useful.

Here’s lookin’ to the future.

Update: Zend Framework 1.8 is officially released.

That better alternative is to simply not stack actions. One practice that I’ve been bringing into habit over the last year or so with my coding is to keep my controllers thinned out. As Ryan states: Fat Models, Thin Controllers.  And as things have rolled out over the last few months, I’ve discovered that is a Good Thing™.

Skinny supermodels beware, your jobs are at risk…

The hardest part of making your models fat would be understanding what the Model really is in ZF’s implementation of MVC. The view is clear, the controller is clear, but what is the model?  With a typical MVC the model is supposed to imply business logic, rules, data access and quite literally everything your application needs to do.  With a well designed model you’ll very easily have DRY code and hopefully efficient code.

Zend doesn’t enforce a specific model to follow, so as a developer that’s something that you have to decide on.

If you have fat controllers your model may be completely swallowed by the controller itself.  If you’re a fat controller designer chances are you’ve got a lot of repetitive code. If your application happens to have database access, and a few classes that extend Zend_Db_Table, chances are the extent of your model is just those classes.  Your model will be very thin and, really, in my opinion, quite useless.  This is how I started with Zend Framework.  And when I was doing this, I was forced to use ActionStack and other strange techniques to get certain things to happen.

As time progressed and I started working on some larger projects, I realized that these fat controllers weren’t going to work very well.  I started transitioning to a fat model and lightening the load on my controllers.  As part of this transition I started creating classes with useful, reusable methods.  Things such as User::getInfo() or Navigation::getGlobalNav() which are pretty self explanitory just by name.  These methods would return usable arrays or iterable objects that would be passed directly into the view via the controller.  The advantage of returning raw data is that the methods don’t need, or even care, about the view.

Using the above,  I could have a controller that’s as simple as this, where the view handles the raw data that gets returned.  All the logic is outside, in a nice tidy, fat model:

<?php
class UserController extends Zend_Controller_Action
{
    function init()
    {
        Zend_Loader::loadClass('Navigation');
        $this->view->globalNav = Navigation::getGlobalNav();
    }

    function indexAction()
    {
        Zend_Loader::loadClass('User');
        $this->view->userInfo = User::getInfo();
    }
}

Hopefully that makes some sense.

I’m guilty of using this style of inclusion in some cases.  Sometimes it’s just easier. I guess it’s time to re-think how I do what I do in these very few and rare cases.  No more ‘../’ in my render statements!

Thanks to Zend Framework In Action for the quick update.

<placemarks>
	<placemark>
		<name>Placemark 1</name>
		<latitude>-79.00</latitude>
		<longiude>42.00</longitude>
	</placemark>
	<placemark>
		<name>Placemark 2</name>
		<latitude>-129.00</latitude>
		<longiude>43.00</longitude>
	</placemark>
</placemarks>

For example, iterating through all the placemarks and extracting the names, lats and longs using javascript is a very tedious affair. In fact, I’ve found it almost pointless to even try without my head exploding.

All of the examples I’ve seen that parse XML in javascript with any ease all use the attributes of XML items.  If this were the case, I’d be using an XML file that looks something like this.

<placemarks>
	<placemark name="Placemark 1" latitude="-79.00" longiude="42.00" />
	<placemark name="Placemark 2" latitude="-129.00" longiude="43.00" />
</placemarks>

That’s a piece of cake with JavaScript, but you know what? Using attributes for every bit of data you want isn’t that bright of an idea.  The schema isn’t very extensible if you use attributes for all of your data points.  What if I want to add a ‘description‘ to each point, and I want that description to contain an HTML fragment? Using an attribute is out of the question for that.

So, What’s an easy way to parse my well built XML file?  I don’t know yet, I’m still looking for that answer.  For the time being I’m using Zend Framework’s Zend_Json to encode the XML output that I generate and return a JSON object.  Maybe this is actually the best way to do it.  After all, JavaScript parsing JSON is fast and super-easy.

Zend_Loader::loadClass('Zend_Json');
$json = Zend_Json::fromXML($xml);

And, pewf I’ve got JSON.

I guess the whole point of this is, does anybody actually know a good way to to parse XML with JavaScript without using attributes for all the datapoints?

Until then, JSON it is.

I found a nice post by Christoph Dorn with a few nice pointers on how to integrate FireBug and FirePHP using Zend_Log and Zend_Log_Writer_Firebug.

My only addition was the use of a ‘debug’ flag that I use in my applications.  Basically, if it is set to true the logwriter will work, if it’s false, it won’t write anything.

if ($config->debug === '1') {
	$writer->setEnabled(true);
	$frontController->throwExceptions(true);
} else {
	$writer->setEnabled(false);
	$frontController->throwExceptions(false);
}

That little snippit in my bootstrap makes all the magic happen.

And with Zend Framework, it’s f’n damn simple!

Zend_Loader::loadClass('Zend_Rest_Client');
$rest = new Zend_Rest_Client('http://maps.google.com/maps/geo');
//?q=1600+Amphitheatre+Parkway,+Mountain+View,+CA&output=json&oe=utf8&sensor=true_or_false&key=your_api_key

$rest->key('YOUR_API_KEY');
$rest->q('1600 Amphitheatre Parkway, Mountain View, CA');
$rest->output('xml');
$rest->oe('utf8');

$result =  $rest->get();
// the whole $result is a SimpleXML object
print_r((string)$result->Response->Placemark->Point->coordinates);

And that’s it.  Save the results someplace useful so you don’t have to hammer the shizzle out of Google (there are query limitations per key).

* I mean almost anything, because you cannot geocode a UK Postal Code, because the Queen and her Royal Mail owns the copyrights on it. Silly, I know.

Normally I’ve always rendered repetitive data by using a foreach on my objects or arrays and then within that foreach I usually render an external file (when I’m not lazy), or even just have a large chunk of html within my view scripts.  When it comes to bigger sites, I want the html fragments to be as simplified and manageable as possible…

That’s where the Parital and PartialLoop view helpers in Zend Framework come in to play.

Before I would have something like this littered throughout:

<ul>
<?php
foreach ($this->rowset as $row):
    echo '<li>' . $row->title . '</li>';
endforeach;
?>
</ul>

Now that I’ve noted the Partial and PartialLoop helpers I can do this:

<ul>
<?php
echo $this->partialLoop('_my_list.phtml', $this->rowset);
?>
</ul>

And get the same result.  As long as ‘_my_list.phtml’ exists in the module scripts folder and contains the necessary fragment to output data from the row, it should work as planned.

One thing to note though, is that the scope of each row that you are iterating through is that of the partial script fragment ($this) – in my original all included way, the context of the row was ‘$row‘

My fragment would look like this:

<li><?php echo $this->title; ?></li>

The partialLoop also has a counter that allows you to know what row you are on and do things such as alternate background colours, repeat headers, or whatever else you feel necessary.  Super handy for data set listings.  I hope that makes some sense.