Sat, 21 Apr 2007 20:55 UTC
So, I will once again find myself in New York City next week, and while I’m there, I’ll be attending New York PHP’s April meeting. If you’re in the neighborhood, drop by. Chris Shiflett will be presenting a talk entitled “Security 2.0.” I’ve seen a sneak peak of the title slide, and this talk will be highly informative—as usual—but this time there will be a twist on the sometimes dry topic of security. You’ll have to come see what I’m talking about; you’re bound to be entertained. I’m looking forward to it.
If you want to attend, be sure you RSVP or you might not be able to get in. Here are the details:
What: New York PHP
When: April 24, 6:30pm
Where: IBM, 590 Madison Avenue, Room 1219
Who: Chris Shiflett is presenting on “Security 2.0”
1 Comment »
Permalink
Tags: new-york, nyphp, php, user-group
Wed, 11 Apr 2007 4:33 UTC
For the second time in two weeks, I find myself back in New York City for a project with Schematic. This is also the second time I’ve ever been to New York, the first time being, of course, just over a week ago. For anyone who hasn’t yet visited New York, if you find yourself flying into Newark and taking a cab into the city, it’ll cost you about $70. However, if you have the opportunity—and it’s nighttime—ask the cab driver to take you through the Lincoln Tunnel (via the NJ Turnpike) rather than the Holland Tunnel. You’ll get a spectacular, panoramic view of the lit-up city from uptown to downtown.
Also, special thanks to Chris Shiflett, who suggested I eat at The Playwright Tavern Act II at the corner of 46th St. and 8th Ave (the location on their website is for “Act I”). They have Murphy’s Stout on tap, and their traditional Irish breakfast is excellent!
After dinner, I walked down 8th Ave. to Times Square, and, along the way, found that my hotel is right next to where Avenue Q is playing. I hope to make it to Thursday’s show, and I’ll surely have to bring my wife next time I’m here so we can go see Chicago.
Now, enough about New York …
Continuing from my post last week of notes on the Zend Framework, I’d like to provide some pointers on using helpers with views in a much more automated way.
Just as views can be automated—that is, you don’t have to instantiate a Zend_View object; the controller does it all for you when you call $this->render() from any controller action—you do not have to explicitly tell Zend_View where your helpers reside, as the manual suggests. Instead, place your helpers in a special “helpers” folder where the Zend_Controller_Action’s initView() can find them.
In keeping with my previous example, your helpers would live in a “helpers” folder beneath the “views” folder:
application/
controllers/
models/
views/
helpers/
TranslateText.php
scripts/
library/
webroot/All helpers contained in this “helpers” folder are automatically available to your views, albeit with a few caveats.
The Zend Framework manual doesn’t make it very clear how to name your helpers. It states:
The class name must, at the very minimum, end with the helper name itself, using CamelCaps. E.g., if you were writing a helper called “specialPurpose”, the class name would minimally need to be “SpecialPurpose”. You may, and should, give the class name a prefix, and it is recommended that you use ‘View_Helper’ as part of that prefix: “My_View_Helper_SpecialPurpose”.
Thus, when I first created a helper, I simply gave it the class name “TranslateText” because I was working on a translation helper. This did not work. So, I gave it another name: “My_View_Helper_TranslateText.” This also did not work. The helper was not available to my views until I specifically named it “Zend_View_Helper_TranslateText.” Then, I was able to access it from a view with $this->translateText(). The file name, however, can be whatever you want.
If you wish to use helpers while using the automated view approach as illustrated in my last post, you must follow this nomenclature when writing helpers. If, however, you choose to explicitly instantiate Zend_View objects, then you may name your helpers however you like. Just follow the instructions in the Zend Framework manual in that case.
A few more things about helpers that the manual does make clear, but I think it’s worth making blatantly obvious: your helper class must have a method that is the same name as the helper in order for it to work; it does NOT rely on the class name and a constructor. Thus, if my helper is named Zend_View_Helper_TranslateText, then the translateText() method is the one that will execute when I call $this->translateText() from within a view. Also, all other methods and properties in a helper are ignored by the view, but you can include other methods and properties for your main helper method to use and call; I would recommend treating these as protected/private since you can’t access them from the view.
I hope this helps further your understanding of the Zend Framework.
Enjoy!
6 Comments »
Permalink
Tags:
Thu, 5 Apr 2007 3:09 UTC
I’ve been working a lot lately with the Zend Framework for a project at work, and in a recent upgrade from 0.8.0 Preview to 0.9.1 Beta, I made a few discoveries that I’d like to share, especially since the manual for the Zend Framework is sorely out of date, and many of the examples are either deprecated or no longer work.
Most notably, I’ve started using the “new way” of using views, which is still undocumented in the manual. Rather than create a new Zend_View object, tell it where my views are, and echo a call to its render() method, I’m letting the controller’s render() method do it all for me. To do this, you need to follow a specific directory structure. For example, if your application is set up like this:
application/
controllers/
models/
views/
library/
Zend/
Zend.php
webroot/
index.phpThen, to make use of the controller’s default render() behavior, add a scripts/ directory under the application/views/ directory. Then, inside the scripts/ directory, create a directory for every controller. The directory must have an all-lowercase version of the controller name without the word “Controller.” So, if you have a CustomerController class, then the directory would simply be customer/.
Inside this directory, create a view file for every action you will render following the same naming conventions. Thus, if you have an indexAction() and an addressAction() you would have the files index.phtml and address.phtml in application/views/scripts/customer/. The .phtml extension is the default for views in the Zend Framework; see Rob Allen’s discussion on the use of the .phtml extension.
Finally, to use the views, you’ll need to initialize them in your controller. Do this by creating an init() method and calling $this->initView() from within it. This sets up the default view for your controller. From within any action, you may now set properties on your view as normal with $this->view->propertyName and you can render the view with $this->render() (there is no longer a need to echo).
So, to recap, with a directory structure like this…
application/
controllers/
CustomerController.php
models/
views/
scripts/
customer/
index.phtml
address.phtml
library/
Zend/
Zend.php
webroot/
index.php... and a controller like this …
<?php
class CustomerController extends Zend_Controller_Action
{
public function init()
{
$this->initView();
}
public function indexAction()
{
$this->render();
}
public function addressAction()
{
$this->render();
}
}
?>... you can much more easily work with views in the Zend Framework.
Note that Zend_Controller_Action::initView() determines the location of the views directory on its own, so you don’t have to tell the application where your views are stored. It determines the location based on the controller directory specified for the current module in use. In this case, we’re using the “default” module, and I’ve specified the controllers directory in my front controller as /path/to/application/controllers/. The Zend Framework also supports the use of different modules using different controller directories, but I’ll talk more about that later as I share more of my Zend Framework discoveries.
17 Comments »
Permalink
Tags: php, zend-framework
