Jani Hartikainen has posted his idea for using forms along with models in a Zend Framework application.

Matthew Weier O'Phinney wrote about using Zend_Form with models. His approach puts a form inside a model, which then uses the form to validate itself. While this idea is not bad, I find it being upside down - I think the form should use the model to validate itself, not the other way around.

Jani describes two alternate methods - using a global model to do the checking or a model-based validation class that would inherit the model's functionality through being extended. He describes each option's setup and potential use (no code is included save for a few small examples).

The PHPFreaks.com website has posted a recent tutorial looking at a tool that can help you protect you and your web applications from possible malicious users - PHPIDS.

PHPIDS (PHP-Intrusion Detection System) is a simple to use, well structured, fast and state-of-the-art security layer for your PHP based web application. The IDS neither strips, sanitizes nor filters any malicious input, it simply recognizes when an attacker tries to break your site and reacts in exactly the way you want it to. Based on a set of approved and heavily tested filter rules any attack is given a numerical impact rating which makes it easy to decide what kind of action should follow the hacking attempt.

They look at the installation of the tool, an example configuration (that sets up some logging and caching settings) and a PHP script to enable the functionality. Then you can use the auto_prepend Apache directive to load it on each page and protect your site quickly and easily.

Chris Hartjes continues his series looking at converting over legacy applications into a CakePHP environment with this third part, a focus on what can be one of the hardest parts - separating out business logic and presentation logic.

Anyway, onto other matters. As you saw in parts 1 and 2, a bug part in having a successful transition from legacy app to CakePHP is having an environment that is well suited to the use of a framework. Having laid out the groundwork for that switchover, it's time to talk about the part of a refactoring or porting that is most difficult: separating your business logic from your display logic.

He talks about fat models, skinny controllers and flexible views with some code to illustrate each. This method makes the models do most of the work while the controllers are more of a go-between for them and the views. The views, then, are pliable enough to work with whatever data might be thrown at them.

If you're looking for a framework to try out on your next Web 2.0 application, Knut Urdalen suggests you give Yii a try.

The Yii Framework is built for speed and the goal is to provide the best possible framework for your next large-scale web 2.0 applications. With it's superior performance, Yii still provides an easy-to-use and highly extensible feature set that is richer than most other frameworks.

If you haven't tried it, he points out the "getting started" tutorial offered on the Yii site as well as some of the performance benchmarks (including those for the next release, 1.0.1).

DevShed continues their series on using CodeIgniter to make a simple blogging application with this new article. It focuses on the next step in the blog's evolution - making it able to accept user comments.

A decent blog application, however, must provide users with a mechanism that lets them post their comments easily, and the simplest way to do this is via an HTML form. Therefore, in the next few lines, I'll be explaining how to modify the controller class and the comments view file created in the preceding article to incorporate a basic web form that permits users to post comments on a particular blog entry.

They start by reviewing the code and application so far, ensuring we're all on the same page. From there, they add code into the controller to handle the form input and make a view to create the form itself.

On the PHP::Impact blog there's a recent post looking at using the popular unit testing PHP framework PHPUnit to test Zend Framework controllers.

Testing a Web application is a complex task, because a Web application is made of several layers of logic. Unit testing a Zend Framework controller can be very difficult, specially for those who are not familiar with the Zend Framework. You can test your action controllers using Zend_Test and/or PHPUnit. Zend_Test allows you to simulate requests, insert test data, inspect your application's output and generally verify your code is doing what it should be doing.

He opts for the second one and includes the directory structure you'll need to set up the tests, an example bootstrap file and a simple controller (AllTests). A simple test example is also included that checks a few things - if its the default action, the first action, parameter names and method names.

Douglas Brown has a few helpful hints to help you write your PHP code defensively, protecting your code from malicious attackers.

The phenomenal growth of PHP applications has also led to a mushrooming of increased quantum of malicious activity. It thus becomes imperative that you write secure PHP code to protect your website. Here are some tips for the same. The three most vulnerable aspects of PHP that can become easily accessible to anyone are XSS (Cross Site Scripting), Global Variables and SQL code.

He details what each is and how you can protect your code against the problems they cause. Some example code is included to give you a better idea of the possible solution.

DevShed continues their series creating a simple blogging application with the CodeIgniter framework with this part of the series - adding in a display for user comments.

In this specific case, the first of these files was defined as a basic controller, and was provided with the ability to paginate the aforementioned blog entries via the corresponding pagination class included with CodeIgniter. However, in its current incarnation, the blog application is pretty limited. It doesn't let users post comments on each blog entry. Thus, in the next few lines I'll be improving the signature of the controller class to address this important issue.

The review the code from before (showing the pagination of the blog entries) and add onto it a new comments method and how to create a new view to show the messages visitors to the site have submitted.

On the PHPBuilder.com site Anthony Corbelli has a new tutorial looking at the differences between using GET and POST in the context of an Ajax-enabled application.

GET is typically used when you simply need to retrieve data and POST is used when you want to change the state of the server (i.e. send/update data on the server). This article will discuss how we use GET and POST methodology in our Ajax applications!

Complete code for his examples is included - both the Javascript and PHP sides. His example handles both GET and POST requests the same way, returning the city and zip information.

On the PHP in Action blog this new post talks about something that's at the core of the front controller for most frameworks - a call to a user function based on the passed in action.

The core of your average web framework is a Front Controller. Front Controllers are commonly considered complex and esoteric. That's a myth. I sometimes brag that I can construct a Front Controller in 15 minutes. Actually, it's doesn't take quite that long. In PHP, a Front Controller can be simplified to just one line of code.

This one line of code, while a very dangerous thing to actually use in an application, illustrates what a front controller does to forward out the request to the rest of the framework. He revises it with a Zend Framework-ish example that splits the request out into a controller/action method.