Link Details

Nice. Now you are just one step away from using PHP as front end (PHP as a better JSP/JSF) and Servlet-Java as back end.

The danger with using PHP as a front end, is that it's too powerful for that. People can't constrain themselves when being exposed to power and tend to misuse it. In this case, putting business logic inside the view. And that's where the mess starts...

Hmm, a valid objection.

You are indeed alluding to a common pitfall with PHP; frameworks try to offer a solution with a MVC model.
Of course, dzonelurker's idea is intriguing since it would bring us back to PHP being a 'Hypertext Preprocessor'. I have no idea what the benefits of this approach would be. Do you?

With Quercus ( http://www.caucho.com/resin-3.0/quercus ) this would absolutely be a possibility. A PHP page can simply retrieve Java objects from any of the Java EE scopes (request, session, etc) and use these objects.

This would allow the exact same way of programming as one does in the so-called Model 2 pattern; A servlet processes the request, calls some business logic, inserts some appropriate beans in the request scope, forwards to a JSP page, that picks up the bean and uses it to direct its rendering and to retrieve the raw data that is to be rendered from.

In the past, a JSP page would use JSTL and EL. With Quercus, that could be PHP instead. The thing is that EL is intentionally limited. It's hard to express business logic with it, just to discourage people actually putting business logic in the view. PHP doesn't have such (intentional) limitation, so although it would indeed bring back PHP to its origins, it may not be the best approach. It's a shame though, since technically PHP may be quite suited for it. But like I said before; with great power comes great responsibility and few people can cope with that..