Python

>>> test = 123
>>> test2 = "ewfwef"
>>> test / test2
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for /: 'int' and 'str'

PHP

$test = 123;
$test2 = "werwe";
echo $test/$test2;

Warning: Division by zero in Command line code on line 1

It’s nice that python tells you what is really wrong here, you can’t divide an integer by a string! PHP on the other hand implies that $test2 is equivalent to 0.
It should be noted that python is doing a trace and PHP is not. Doing a trace on the error in PHP would give more information but since PHP is very weak with types, you would probably have to notice the error on your own.

The concept is that I created a component to handle displaying the navigation menu and included the component in the layout. All the component has to do is remove the current page from a list of pages that are retrieved from the global configuration file and display them as a list. To do this, I simply created a component – you can look here to find out how to do that in detail.

What it meant for me is that I created a module in my application called “navigation” (I made a folder called navigation in the modules folder) and then in the navigation/actions folder I created my components file: components.class.php. This is where the logic for your component goes. Then, I created a file (partial) called _navMenu.php in navigation/templates (we’ll get to why you call it that in a second) – this is the template that is displayed for the component.

The component logic

The logic for the component was as follows:

// apps/app_name/modules/navigation/actions/components.class.php
class navigationComponents extends sfComponents
{
  /**
   * Executes the building of the navigation menu.
   */
  public function executeNavMenu()
  {
    $route = sfContext::getInstance()->getRouting()->getCurrentRouteName();
    $this->pages = sfConfig::get('app_navpages');
    unset($this->pages[$route]);
  }
}

Basically, you’re components.class.php file is what includes all of the components – since mine only includes one component (navMenu) I probably could have just had the class inherit from sfComponent, but I think that this may come in handy later if I ever want to add another component. Now, the name of the method (executeNavMenu) is important – it determines what partial in the templates folder will be displayed (_navMenu.php – I told you we’d get to that) and it determines the name that will be used to include the component in the layout (or whatever view you may want to include the component in). My particular component is very simple – it gets the current route (as defined in routing.yml) and gets a list of my possible navigation menu pages as defined in my app.yml file:

// apps/app_name/config/app.yml - app_name is not the actual name...
all:
  .array:
    navpages:
      homepage: { name: 'Home', route: '@homepage'}
      person_index: { name: 'Manage Users', route: '@person_index' }

Once I have these two bits of information, I take the item for the current route out of the list with the line unset($this->pages[$route]). In my routing.yml file, my homepage route is defined as the following:

homepage:
  url:   /
  param: { module: home, action: index }

So, for example, if I am at my homepage (http://example.com/), $route will contain the string ‘homepage’ and the item with the key ‘homepage’ will be removed from the list. Then, the variable $pages will be available in my template (partial) to be displayed.

The Component View

The code for the _navMenu.php partial is even more simple:

<div id="navigation">
  <ul id="nav">
    <?php foreach ($pages as $page): ?>
      <li><?php echo link_to($page['name'], $page['route']); ?></li>
    <?php endforeach; ?>
  </ul>
</div>

In fact, it’s so simple that I don’t even think it needs explanation.

Including the Component in the Layout

Now all that remains is to include the component in the layout. That can be accomplished with this one-liner:

<?php include_component('navigation', 'navMenu'); ?>

The first argument is the module in which to find the component and the second argument is the name (which I mentioned earlier) of the component itself (the name of the method minus the execute on the front).

As you can see, all of the individual pieces are very simple, and when you put them all together, you get a nice, logical way of building a contextual navigation menu.

I’m not sure if I missed a step of if this is a system specific problem but basically I went to run the “symfony propel:build-module” command to genereate my module files and I got this error.

Fatal error: Class ‘PersonForm’ not found in /var/www/cam/trunk/lib/generator/sfModelGenerator.class.php on line 321

The “PersonForm” class was, as the error indicated, no where to be found.  It turned out that I needed to run the command “symfony cc” which clears the symfony cache of files.   I also had to run the command “symfony propel:build-forms“  in order to get symfony to build my modules.

So to re-cap

1. Run $ php symfony cc
2. Run $ php symfony propel:build-forms
3. Run $ php symfony build:module  (Params)

Once I did those steps the build:module step worked perfectly and I was able to view the skeleton application at my dev.php/person url.

Symfony seems to be very very powerful and I’m excited to learn how to develope applications with it.

This is what happened to me today.  I have been working on the Jobeet tutorial and, on day 16, they asked me to implement an XML/JSON/YAML API module. Of course, since it’s a tutorial, they give you all the code and I was mostly just copy-pasting, but once I started poking around after completing part of the chapter, I noticed that the production environment only displayed one record while the development environment displayed (correctly) about thirty records. I knew this wasn’t right. My first reaction was to try clearing the cache – no luck. Now I had no idea what to do since I’m a symfony noob and the only thing that I thought was really different between production and development was that one cached and the other didn’t (and the databases could be different if you wanted to set them that way, but I hadn’t – it’s just a tutorial, after all).

Well, to make a long story an amazing amount shorter, I went digging and found that a URL that was being generated in a loop to be used as an array key was always the same  (but only when debugging was disabled).  After some more digging, I found that the reason that it was always the same is that the method used to generate the URL was supposed to take an array as an argument and I was passing it an object instead (because the tutorial told me to).  Now here is the interesting part:  the reason this did not work was, indeed, because of caching.  It just so happens that the symfony hashing function for its URL cache uses the PHP function array_merge().  Now, I haven’t looked into this in depth, but I guess when trying to merge an array and an object this function isn’t the best.  However, when there is no caching enabled, the way symfony generates the URL is by using a custom function called mergeArrays:

protected function mergeArrays($arr1, $arr2)
{
  foreach ($arr2 as $key => $value)
  {
    $arr1[$key] = $value;
  }

  return $arr1;
}

Now, if $arr1 were an object this wouldn’t work since you can’t access members of an object with the [] operators, but, since my object was being passed into $arr2, it worked fine.

The one thing I cannot decide now is if this blog post is a warning against the dangers of development vs. production environments, rewriting functions that are included in the language, dynamic languages in general, or something else I haven’t thought of. I do know I learned several things from the experience, though. First, it’s almost always my code that’s wrong – not the framework. Second, just because it works in development doesn’t mean it will work in production. And third, validate your input – if you’re expecting an array, make sure it’s an array and not some random object.