Improving on his last post about creating a bytecode compiler in PHP, the Sankuru blog has a new post in the series looking at extending the basic compiler to add support for if/while and do while logic.

In order to obtain a turing-complete programming language, that is, a language in which we can implement and execute any arbitrary algorithm, that is, that other turing-complete machines can execute too, we now need to add a way of (conditionally) branching, that is, the IF statement, and at least one way of repeating statements, that is the WHILE or the DO WHILE statements.

He includes a simple TL-based script as an end goal for the compiler to be able to execute and shows how to add rules for it to the lexer/parser. Rules for the "if" are relatively simple, but there's a hitch in dealing with embedded "while" statements he had to work around. The post ends with the bytecode results for the sample program and the resulting output from the compiled versions execution.

In a bit of a ranting post on the WorkingSoftware.com.au blog Iain Dooley shares his opinion about most of the code he's seen, specifically related to templating engines: "Your templating engine sucks and everything you have ever written is spaghetti code (yes, you)".

Templating is a real hot button in the web development community. [...] The high horses that people usually get on are that all too familiar TLA MVC (Model/View/Controller) architecture and "separation of presentation and business logic". The poor pedestrians upon which they look down are those who have written "spaghetti code" - templates where presentation logic, markup, business logic, database access configuration and whatever else you might imagine are mixed up in the same file. Well, I've got some news for you: you're all wrong.

He points out that, with most of the major templating tools out there, there's most people still put some sort of business logic in their templates. Rarely will you find a "pure" template that only echoes out the data. He gives an example of a Mustache template with "empty" logic in it. He shares a new term his coined too: "Template Animation". This is the separation of the templating process as it is usually done and splitting it so that the output is a modified DOM resource rather than a static template.

He talks about some of the advantages of this approach and an example of its use in an example of a logged in user vs not logged in user as well as a brief discussion of Markdown/HAML.

The only thing that Template Animation advocates is that the technological barrier between the frontend and the backend is never crossed - that our templates are truly logic-less.

There's lots of comments on the post already - everything from support of the idea to systems that already implement this sort of idea to disagreeing opinions.

In a recent post to his blog Marco Tabini talks about what he calls the lost art of using your brain, the fact that people seem to be relying more on the contents of other peoples' brains instead of their own.

The world of technology is riddled with inhabitants who treat tools as if they were religions. OOP, unit tests, patterns... these are all instruments that are supposed to make some jobs better, and not theological formulas that will magically make every single line of code written on the face of the Earth better. And yet, the vast majority of people treats them like they are, sparking everything from language wars to endless-and pointless - discussions on whether a particular technique is better than another.

He goes on to say that the tools developers use every day aren't just limited to the technology that makes them up. They're there to make things easier, but if the developer using them doesn't take the time to engage their minds to use them correctly, they're practically useless (100% code coverage, for example). He shares his three reasons why he thinks this issue is so wide-spread and the steps he suggests to push out of this way of thinking and back into a more mindful, thinking sort of development path.

On the Stubbles blog there's a recent post that talks about a feature they introduced into the framework - annotations - with high hopes it would give them more flexibility in how things worked. As Frank Keline says, though, "it's not such a good idea at all".

The most simplest reason for this is the idea that annotations are markup. They mark (or, to keep the notion, annotate) code as being special or to be treated in some special kind of way, depending on the scenario where the code is used in. [...] From a design point of view this makes it clear why annotations should not contain logic. If annotations contain parts of such logic, it becomes splitted and possibly cluttered throughout different classes.

He goes on to talk about a second reason why he doesn't think they should be considered first-class in an application - it doesn't promote code reuse. For example, if you define them on a method, there's no way to use that method without them. He puts this into the perspective of the Stubbles framework that currently uses them and how he's changed the logic to live in special classes instead. He considers other changes like places annotations can be used and having different annotation classes.

Ralph Schindler has put together a new post for his blog about some of the best practices for using exceptions in PHP 5.3 - specifically dealing with some of the new functionality that comes with this latest PHP version.

Exception handling in PHP is not a new feature by any stretch. In this article, we'll discuss two new features in PHP 5.3 based around exceptions. The first is nested exceptions and the second is a new set of exception types offered by the SPL extension (which is now a core extension of the PHP runtime). Both of these new features have found their way into the book of best best practices and deserve to be examined in detail.

Some of the features he talks about were pre-PHP 5.3, but the focus is largely on these new features. He gives a bit of a background on exception handling in PHP and how custom exceptions could be thrown. He then moves on to the new features - first nesting exceptions and then some about the new core exception types (found here). All that being said, he includes some code to show the dynamic/logic/runtime exceptions in action including a look at best practices in library exception handling.

Brandon Savage has posted the fifth part of his "Peer Review" series where he's taken a sample application and worked it over - refactoring, updated to meeting coding standards and abstracting out interfaces to simplify the code. In this latest article he looks at a method to improve the business logic behind the scenes.

So far, we've done quite a bit of work on our Twitter class, making it better. There's still work to be done, though, especially improving the logic. The Twitter class we have now has a number of logical flaws in it that we need to address. Additionally, there are some logical flaws that we started with that I want to highlight, even though we've already fixed them. Let's get started with those.

He looks at a few things like setting the host name as a property, using the return of the HTTP request and handling exceptions (like when Twitter's down). The resulting code is included.

Jim Plush has taken a look at his models in the Zend Framework and has rethought them a bit to work with a bit more complex process than the usual simple sort of Zend Framework application.

The current active record/table gateway patterns just aren't going to cut it for the complex business logic that's approaching. I'm starting to lean towards the domain model approach which would increase the initial complexity of the design but allow for the flexibility for future changes and features. The issue is with where to put your business logic?

He diagrams out his potential solution and includes two bits of code showing how it would work in practice. He's soliciting opinions as to the validity of this approach too, wondering if its the best way to go for more complex application structures requiring these sorts of business requirements.

On DevShed today they continue their introduction to CodeIgniter series with this new tutorial looking at views nd how to move some of the presentation logic out of them an into a "sub-view container".

Manipulating views with CodeIgniter is a straightforward process. [...] However, CodeIgniter gives PHP programmers enough freedom to handle views in several useful ways, which can speed up the development of web applications. Therefore, if you're taking your first steps with CI and wish to learn some handy approaches that will help you work with views in a truly painless fashion, then start reading this tutorial now!

Their method defines a reusable view "container" (their content_view.php) to handle the looping that was previously just done in the one view for the user listing. This makes the content_view script reusable across more than one view and standardizes some of the look/feel in the view's output.

The O'Reilly School of Technology now offers a series of PHP certification classes developers can attend to learn more about PHP and SQL on a variety of projects.

The PHP/SQL Programming Certificate Series is comprised of four courses covering beginning to advanced PHP programming, beginning to advanced database programming using the SQL language, database theory, and integrated Web 2.0 programming using PHP and SQL on the Unix/Linux mySQL platform.

They currently offer three courses:

• Introduction to PHP
• PHP/SQL 1: Introduction to Database Programming
• PHP/SQL 2: Relational Theory and Logical Design

Another class will be released in December 2008 - PHP/SQL 3: Seamless Web 2.0 Integration . The classes come it at a bit under $400 USD and include access to an online sandbox for testing (complete with web server, unix-shell and database installations). Completion of all four courses earns the student a certification from the University of Illinois's Professional Development department.

The Zend Developer Zone has posted a new article today with three tips to help you make your code a little easier to understand (both by other coders and yourself down the road).

Producing code that clearly conveys a developer's intent is key to any well written application. That not only applies to PHP, but every programming language. Developers who emphasize the creation of legible code tend to create applications which are easier to both maintain and expand upon.

His tips include suggestions about keeping conditional logic clean, using "less PHP and more HTML" and to make the best possible use that you can out of sprintf "and friends".