Project ZNF: PHP5 Struts-like MVC framework

[aronnax]

Hi, my name is Alessandro 'Aronnax' Rossini and I want to let you know the launch of a new project called ZNF.
The goal of this project is to provide an open source framework for building PHP5 enterprise web applications. It's based on the Apache Struts project of the Apache Software Foundation, available at http://struts.apache.org.
This is not the first attempt to rewrite the Struts implementation, or part of it, in PHP, but after spending a lot of time studying existing open source frameworks, like Phrame, PHPMVC, Struts4PHP, Seagull and Vida, we choose to reimplement a brand new framework from scratch for many reasons. First of all, all the mentioned frameworks, except Vida, are written in PHP4 and we believe that its object engine (Zend Engine 1) is too limited for developing enterprise level web application. At the same time the code analyzed is written without a rigorous approach (coding standards, compliance to W3C standards, output of notice/warnings, lack of documentation/examples). Last but not least frameworks claiming to be a porting of Struts have made no code optimization during the porting from J2EE to PHP.
ZNF is free software released under GNU/LGPL license, the official ZNF home page is at http://znf.zeronotice.com. You will find the main package, a PEAR compatible package and the developer's guide.
The project has been developed by me and Graziano 'FreeJay' Liberati, we are searching for comments, feedback, bug signaling and best of all new developers. Any kind of contribution will be appreciated, if you find the project interesting join the team!

Best regards.

[McGruff]

Does this come with a full suite of unit & etc tests?

[Captain Proton]

I don't like Struts.

[arborint]

Struts in Java is a beautiful thing. I have used it and it certainly makes building large sites with a team a structured process.

I think the central ideas of Struts are shared by many frameworks, but the most successful PHP frameworks have abandoned the idea of porting Struts. Even the Java world is moving away from Struts to more lightweight container based frameworks.

I would ask Aronnax and FreeJay if they have addressed all the reasons why porting Struts to PHP is a bad idea because of the lack of an application server?

[BerislavLopac]

I would ask Aronnax and FreeJay if they have addressed all the reasons why porting Struts to PHP is a bad idea because of the lack of an application server?

I'm not disagreeing with your point here (i.e., porting struts to PHP is a bad idea), but I am with the second part. PHP is an application server itself, in all the senses this phrase covers that I know of -- well, not exactly by itself, but in a conjuction with a Web server underneath.

I would even go as far to say that PHP is basically a Web application platform using its own proprietary language instead of some more widely used like Java or ECMAScript.

[arborint]

but I am with the second part. PHP is an application server itself, in all the senses this phrase covers that I know of -- well, not exactly by itself, but in a conjuction with a Web server underneath.

I think the difference is that with an application server the application is compiled and installed into the application server where it's internal state is maintained as a running program. This is very different from PHP where you always start with no state and have to load what you want manually. That is what makes for the key differences between PHP and Java frameworks.

[BerislavLopac]

I think the difference is that with an application server the application is compiled and installed into the application server where it's internal state is maintained as a running program. This is very different from PHP where you always start with no state and have to load what you want manually. That is what makes for the key differences between PHP and Java frameworks.

In other words, persistence between requests is achieved by keeping the variables/objects/state in memory, while in PHP it is (or can be) achieved using flat files, database etc. Pot-a-to, potato.

Even PHP has mechanisms, like sessions, to keep states between requests. It just gives you a greater flexibility of how to achieve it.

[arborint]

In other words, persistence between requests is achieved by keeping the variables/objects/state in memory, while in PHP it is (or can be) achieved using flat files, database etc. Pot-a-to, potato.

Even PHP has mechanisms, like sessions, to keep states between requests. It just gives you a greater flexibility of how to achieve it.

I didn't say you couldn't achieve simlar things using either Java or PHP. My point was that you have to do very different things to achieve the same result. For example having a single, large memory resident data map with information about each pages' configuration makes sense with an application server. Loading a very large data map every request in PHP does not make a lot of sense. Another example is the difference between how Hibernate does what it does and what can be done in PHP also demonstrates this difference as well.

[BerislavLopac]

I agree. My point was that what makes PHP an application server is the fact that it can do all the things an app server can, although a bit differently than most app servers. And that makes it an app server.

[R. U. Serious]

My point was that what makes PHP an application server is the fact that it can do all the things an app server can, although a bit differently than most app servers. And that makes it an app server.

So basically every webserver that supports cgi/fcgi (and thereby every language you can use with it) is an app server by your definition, or maybe even every language that supports sockets (and thus allows you to reimplement a webserver on your own).
I am not sure wether it is helpful to define the term so broadly. I find the narrower definition (as per arborint) to be of more use.

[BerislavLopac]

I am not sure wether it is helpful to define the term so broadly. I find the narrower definition (as per arborint) to be of more use.

You might have a point here, although I'm still very uncertain what would be the most precise definition of a (Web) application server.

The Hitchhiker's Guid... I mean, the Wikipedia is not of much help here: all it says is "An application server is a server computer in a computer network dedicated to running certain software applications. The term also refers to the software installed on such a computer to facilitate the serving (running) of other applications."

[Captain Proton]

That's what you get when marketing people make the concept definitions, as is the case in the IT industry today

[stereofrog]

In other words, persistence between requests is achieved by keeping the variables/objects/state in memory, while in PHP it is (or can be) achieved using flat files, database etc. Pot-a-to, potato.

The key difference between servets and cgi (or mod_php) is that servet is loaded once and keeps running between requests. This is much like desktop (or daemon) programming, where the single physical instance of running program handles mutiple events or requests.

And no, php is not an application server. Although it's hard to define "application server" formally, it's easy to understand by example.

[aronnax]

Does this come with a full suite of unit & etc tests?

Full unit testing, probably using PHPUnit2, is not yet done but it's scheduled for the 0.8.0 release. If new developers will join the team it could be done before.

[aronnax]

I would ask Aronnax and FreeJay if they have addressed all the reasons why porting Struts to PHP is a bad idea because of the lack of an application server?

The framework is titled "Struts-like" and not "a port of Struts" simply because we've taken from Struts all the ideas that, according to us, could be successful in a PHP5 environment.
We've replicated the behavior of Struts's RequestProcessor, ActionForm and Action classes, we've also followed the naming conventions for the packages/classes. The rest of the features has been developed keeping in mind the absence of an application server, in few words for each request variables/objects are created and destructed.
For example the configuration of the front controller is defined in a XML configuration file. What happens in Struts is that this file is parsed and, thanks to the application server, kept in memory for all the time of execution of the application. In PHP this is not possible but it's even unacceptable that the configuration file would be parsed at each request, like happens in many of the cited PHP frameworks claiming to be a port of Struts. What we've done is a chaching mechanism that, at the first request and once the configuration is validated, parses and loads the configuration in an associative array and serialize it to the filesystem. For every successive request, of course if the configuration file is leaved untouched, the framework loads and works only with this array and not with an XML tree, making it extremely fast compared to other solutions.
Except the roboust implementation of the framework and other cool features, we also think that the developer's guide is very complete and this is one of the key feature where other frameworks doesn't make a lot of work, leaving the API as the sole documentation for developers.
I hope someone here would look deeper at the project in order to have feedback of any kind, anyway thanks for interesting.

[BerislavLopac]

What we've done is a chaching mechanism that, at the first request and once the configuration is validated, parses and loads the configuration in an associative array and serialize it to the filesystem. For every successive request, of course if the configuration file is leaved untouched, the framework loads and works only with this array and not with an XML tree, making it extremely fast compared to other solutions.

I have plans of making a similar application-level persistence for PHP5, although I intend to make it more universal. It will be based on SQLite instead of filesystem, so it will probably be very fast.

[Dr Livingston]

It will be based on SQLite instead of filesystem, so it will probably be very fast.

But not very flexible in the true nature of the term of what a Relational Database Management System represents. SQLite is a poor mans excuse for a database, much like SimpleXml is a poor mans excuse for the DOM, but that's a personal point of view

[mx2k]

sax, simple xml, and dom xml (even php xpath) all have their places.


so this thread isn't totally hijacked

aronnax ->

good job with the documentation, its a pet peeve of mine. and job prefixing your classes. and providing alot of graphs


i have to ask though, are you guys using smarty or have it intregrated with the frame work? (have to ask cause of the code examples)

also do you guys have an HttpRequest class or similar function to check for magic quotes and act according? cause i saw a bunch of addslasshes() on post data in the code examples.

will you be putting in code examples in the api documentation?

and will you build chms of both documents ? or place the document in other versions other than pdf? flash paper? (i have 2.8ghz cpu and 1.5 g of ram and acrobat still takes its sweet little time. )

also what about a traditional error handler in case of people using php 4 code or with trigger_errors or php's core errors and etc, how are they handled?

[aronnax]

i have to ask though, are you guys using smarty or have it intregrated with the frame work?

also do you guys have an HttpRequest class or similar function to check for magic quotes and act according? cause i saw a bunch of addslasshes() on post data in the code examples.

will you be putting in code examples in the api documentation?

and will you build chms of both documents ? or place the document in other versions other than pdf? flash paper?

also what about a traditional error handler in case of people using php 4 code or with trigger_errors or php's core errors and etc, how are they handled?

We make use of Smarty and PEAR_DB libraries in our framework, but, as reported in the documentation, view and model layer classes are to be considered as helper classes, you can use them or continue using your preferred technologies.

As regard the check for magic quotes, this is not yet handled by ZNF, we will probably add a BeanUtil class in next releases in order to automatically populate ActionForm properties, and probably this will be the best place where to add this and other kind of checks.

The documentation has been written with Latex, so possible output formats are dvi, ps and pdf, we choose the last one because is the most widely used. It's possible to convert Latex to HTML but the result is very ugly, I don't know if there are other possible output formats, proposal are welcome! Some code example are already present in the API but we will continue to focus to the News Demo example because we think it is more useful for new developers.

PHP4 style error handling for now is leaved untouched. We are evaluating to switch to PEAR_Error/PEAR_Exception once PEAR version 1.4.x is out.

Would you like to contribute in some of this topics? It will be appreciated
Regards.

[bonefry]

Wow, another PHP framework.

I really hope some day a really good framework will replace all those wannabe. PHP really lacks a good framework. I don't know if Struts is such a good MVC example for PHP, but it's at least the best we've got, so stick with it.

A piece of advice: drop Smarty from your project and use at least a template manager that have tags written in XML. When all the world is starting to use component and event based arhitecture (asp.net, tapestry, jsf) with templates that can be designed with visual tools and that can be parsed with XSL, only PHP does a really good job of being stuck with that dinozaur.

You say that one can use any template manager with your framework, but that's exactly what's missing from the PHP puzzle, a good standards aware template manager. Why not consider making a good template manager ? JSP like, or Cocoon like ?

[mx2k]

i'd still prefer a couple of good frameworks over one.

i think that the best way of doing a templating system is something still heavily debated. One problem with events based architechture, in php (seeing how php is mostly web based), it would could probably be extremely tied to javascript which is not enabled on all browsers....even in asp.net there are firing issues due to that fact and just the way that not all browsers do what is expected by the framework and etc.

and it seems that most php frameworks are developed from small groups here and there, and it would probably take a bigger effort on a wider scale to really get something solid on such a scale on any foreseeable near future. Even harder than that, you have to get everyone to agree to a certain road map or have some kind of benelovant dictator that people would actually follow.

its alot of work, alot of testing, alot of documenting, and in serious need of being open to various possibilities, not what is working for other languages.

imho that probably what holds back alot of projects is trying impliment something done in another language in php as closely as possible. php is not java, nor is it c# or what have you. play to it strengths, not its weaknesses.

[Dr Livingston]

i think that the best way of doing a templating system is something still heavily debated.

Indeed, but to capture the nature of the web page generation life cycle, you really need to consider the Composite pattern, as in doing so, you'll notice a lot more flexibility.

One problem with events based architechture, in php (seeing how php is mostly web based), it would could probably be extremely tied to javascript which is not enabled on all browsers....even in asp.net there are firing issues due to that fact and just the way that not all browsers do what is expected by the framework and etc.

That is really a client side issue, and not an server side issue. By the definition of event based architecture, I see this being solely server side. You can't depend, and nor should you, depend on the client, that's the number one rule of web development.

Do so at your peril

[mx2k]

That is really a client side issue, and not an server side issue. By the definition of event based architecture, I see this being solely server side. You can't depend, and nor should you, depend on the client, that's the number one rule of web development.

maybe i'm totally naive, (ok probably more than maybe when it comes to any sort of programming, i tend to be better at xhtml/css/photoshop, and the occasional sound stuff etc). but if you are in need of user input/interaction, how would you not be tied in somewhat to the client side/GUI? ( which is probably way more of an issue on the web than desktop, where the gui is a little more consistent in the way that it responds and acts.)

and what do you take/have as the definition of event based architechture? (seeing how i find there are 5 definitions for every programming word ever invented, quite annoying for communication purposes.)

Off Topic:


do we have a thread that has a bunch of definitions of patterns/ vaque terms, and technobable (such as enterprise, dispatcher, w3c and etc?) somewhere here on sitepoint?

[Dr Livingston]

Web based UI have upto now been dumb, but this is I must say, this perspective is going through a process of change in the forseeable future. But for event handling, there is a difference between client and server side event handling.

On the client, an event handler may be required if someone clicks on a button, but on the server, an event handler may be kicked off based on a parameter passed via the url, or based on a cookie, there is a subtle difference but an important one.

The two don't interact, be it a user interface or not. Well, that's my definition of event based architecture anyways, and how I see it, but the internet has new developments all the time, so I suppose I'll at some point, need to change my point of view huh?

[mx2k]

seeing how there are very few absolute truths, if any for the web, i suspect we all have to change our p.o.v sometime or another. unless we just want to be irrelevant along with alot of those generation 1 and 2 websites still floating out there. (got to love those dancing 7up spot gifs, babies and under construction signs).