He highlights syntax, available libraries and string handling as PHP’s strengths.

He has some problems with the scoping rules and with the lack of namespaces.

Reading between the lines, I also wonder if he might prefer a stricter error_reporting setting.

Perhaps as a PHP advocacy issue it might be helpful to have a ‘PHP for Java programmers’ chapter of the PHP manual on php.net. I’m not sure how far something like this might go, but the seed seems to be there. A while ago, I started to compare the PHP response handling to Java’s HttpServletResponse. Request Handling is here.

A comment on this post is disturbing. It calls PHP ‘dangerous’ from a security perspective because of the recent phpBB vulnerability. To be fair, I have to admit that the /e modifier of preg_replace is obscure. (I’ve started compiling a list of Security Sensitive Functions in PHP.)

I used to think so, but now having refactored some existing applications to use MVC, i see the value.

In my unscientific comparison of PHP and Java Job Markets six of ten java jobs ask for some Struts knowledge. While I am willing to believe that Java programmers are masochists, one cannot discount the possibility that there is value in its use.

Another way to approach the issue is to look at this Java framework comparison. It compares the same CRUD application written in Struts, Spring, JSF, Tapestry, and WebWork. The thing that I found striking about the comparison was how “crufty” the struts implementation was in comparison to the others. And yet, none of the others were mentioned in my 10 job sampling. Again, it seems like Struts must bring something to the table.

It is worth remembering that Struts did not originate inside Sun and get pushed out as a bloated vendor standard. Rather it evolved into a de-facto standard of what MVC means on the web as an open source project. I think this growth in use is an indication that web MVC has value.

Is there confusion over MVC?

Yes. Many of the “what goes where” arguments are a bit like trying to count the number of angels that can dance on the head of a pin. In practice, a 100% separations M, V, and C concerns is almost impossible and not even desirable. Yet, it turns out that making some kind of distinction between the concerns is helpful.

Adding to the confusion is the fact that most MVC frameworks do more than just MVC.

I tend to find that the broader your definition of MVC, the more trouble you are going to have with the “what goes where” and “where does this go” questions. In that light, I tried to write up a fairly strict and complete definition of Model View Controller.

I like to use an analogy from the GUI era. If you were writing a GUI application for the Macintosh in 1987, it was hard. Hello World was 50,000 lines long. (at least it seemed like it.) You were responsible for your own event loop and dispatching OS events into your application. Every application re-invented the wheel.

If you are writing a windows GUI application in 1997, you would use a tool like Visual Basic or Delphi to apply the MVC pattern (well really DocumentView variant) to your GUI applications. Both tools take the OS event loop (controller) away from the programmer and dictate an application structure. Trust me, productivity in these environments was leaps and bounds better than the old way. The emergence of Visual Basic and Delphi in the early 90s were just a sign that programmers were getting a handle on how to write GUI applications

I think we are seeing the same transition now in the web application space. Web MVC brings a standard structure to web applications, and in a way, once again takes over the OS event interface for web applications. In 2007, writing a web application without an MVC framework will seem as quaint and be as rare as a polling event loop is today in a GUI application. The emergence of web MVC frameworks is a sign that we as a profession are mastering the art of building web applications.

Do you have a release date planned for the next version?

Ah, the release date question. We are certainly overdue. Here is where things stand.

The core framework in CVS is in very good shape. We have 3332 passing tests and 5 failing tests. The failing tests are relatively minor. I would like to fix them before release, but don’t see it as absolutely necessary.

I feel the biggest obstacle right now is that many of the example programs that we have in WACT are either obsolete, broken or unfinished. They are mostly broken due to the incompatibility of changes within the controller layer from the last version. I would like to see working (and hopefully unit tested) examples for the release. I don’t want to make a release with code that errors out.

The current controller architecture in the CVS version of WACT is very different from what is in the previously released version. After writing what is there now, i have modified my thinking on what a controller framework should look like. I’ve written up some of the theory of this on this Model View Controller page. I’ve been working on a proof of concept of this, which I think will become the final WACT controller layer.

As such, I am reluctant to go through the examples now and update them to the current controller when I know that I will have update them again. I am also reluctant to expose a brand new API in the release which I already know will go away.

I’ve decided I want to work on the controllers and not the examples right now. That of course doesn’t preclude anyone else who wants to work on the examples from doing so and getting us into releasable condition. Thats just how I want to spend my time right now. If we are going to release with what we have now, which i am not opposed to, someone else will have to step up and push that.

Its possible that my controller ideas won’t work out. I’ve just reviewed the 3.0.0dev version of Mojavi. I have to say I am impressed. I have looked at most of the controller frameworks on this page and i have to say that Mojavi is the only one that i would seriously consider using myself. It has the right combination of support, maturity, and good design. If my experiments with MVC don’t pan out, i would seriously consider ditching the current WACT controller layer in favor of Mojavi integration.

So thats where I am at. I would personally like to see more of the controller issues resolved before the release goes out the door. I would like to feel as good about the controller layer of WACT as I do about the rest of it.

I should finish up with a project soon and have more time to devote to WACT.

When will the next WACT release be? I refer you here.

Marcus also asks:

The bit that I’ve never understood is, what is a DataSpace?

The DataSpace concept has evolved over time. in WACT, DataSource is an interface that allows an object to expose properties though a generic protocol. The DataSpace class is a convenience base class that helps implement this interface. The DataSource interface could be considered equivalent to the properties portion of the Java Beans specification. You could think of any object inheriting from DataSpace or implementing DataSource as a bean in java terms. However, I would probably compare it to the more dynamic Key Value Coding from Objective-C.