By Harry Fuecks

PHP and application evolution

By Harry Fuecks

Ian Bicking provokes some interesting thoughts in PHP and Application Evolution, in context with Python and Zope, inspired by this enlightened comment on that article I blogged a while back.

I think Python’s imperative approach is a real feature. Starting on an application by building objects (or doing “whole design”) is a bad idea, unless you know the domain well

and then from the comment he links to;

PHP object orientation was minimal and used only for 3rd-party packages (which is the way it should be in web apps) and it’s syntax is also very simple.

If we think about web apps as, typically having three “layers” (even if they can’t be distinguished in source code) – a data layer (data fetching e.g. from db), an application layer (typically thin in a PHP app but might include simple number crunching, sorting and so on) and a presentation layer (responding to incoming requests, rendering HTML), the approach that seems most successful / down to earth (in terms of getting a project finished / reaching working prototypes) is OO for the data layer, procedural code for the presentation layer and a mix of the two for the application layer. From my own experience and from looking at successful apps like WordPress, so long as you don’t go wild with global variables, it’s hard to fail with this approach, at least until your app really starts to grow.

Meanwhile Jeff has done an outstanding job with laying the foundations of WACT’s MVC implementation; even if PHP isn’t your cup of tea, it’s worth exploring what he’s done. The flip side of the coin though is, as you can see from the reference CRUD application, there’s suddenly alot of classes out there, even for a relatively simple app. Talking to Jeff recently, it’s possible that the current design is going to get “dumbed down” again eventually – what’s been lost is that essential simplicity. In building a really flexible MVC implementation, making unusual use cases possible seems to prevent make common use cases easy.

Anyway – just musing on the state of the Elephant.

Otherwise phpPatterns (and my email) has been down the last few days. The provider of the DNS service I was using decided to wait for the week I went on holiday to make radical changes. Hopefully will will be back up within 24 (any urgent email; please resend).

Don’t you just love it when that relaxed holiday feeling instantly evaporates on returning home?

  • I use OO for database abstraction, business objects and template parsing, and then use procedural code to glue them all together.

    I had an older style framework that used OO as much as possible and it just got too messy. I ended up with so many classes it became a nightmare to maintain.

    The trick with application design in PHP is to balance out the nice theoretical approaches with a healthy dose of realism and practicality.

    Like you mention Harry, the flexability to do the things you want to do some of the time comes as the expense of doing things the easy way most of the time. PHP gives use the flexability to create apps that work in either fashion. This is the Achilles (spelling?) heel that will undo a lot of PHP apps unless they bear this in mind from the start.

  • Appreciated the thoughts. Between the PHP world I sometimes live in and the Flash Actionscript world I always live in, I hardly dare write a line of code these days without worrying that it’s not OO enough. But as you’ve pointed out here, that has sometimes come at a great expense- like spending several hours making a class flexible enough to allow for situations I most likely will never encounter, when I could have created what I needed in a fraction of the time.

  • The nice thing about OO is that you can always take advantage of inheritance for those “special” or “hard to come by” cases. That’s always the other option. Just leave out the special functionality from the base class. Not always possible though.

  • ausurt

    I use OO throughout all my current PHP projects. The reason is because I can easily transfer one piece of one project to the other without really changing anything. I do use CRUD in the DAO and use a Gateway for general queries. These are managed through the Manager, but there is also a Query file that Queries across multiple tables, but only really relates to what is being retrieved. This is made even easier with PostgreSQL views. I dont feel this is a bad layout, but I do believe it needs some work to make it a better layout. I am probably a novice PHPer, but it is an easy language to get into. And I also dont have any previous programming experience.

  • I don’t see PHP as a web scripting language, but as a web integration language. Because we are building a pretty complex N-Tier app. with a wide variety of network and DB resources and a web services layer with an app. layer on top of that, we have a pretty thick domain layer. That layer is heavily OO.

    We sometimes feel we are pushing PHP pretty hard, but guess what? So far it’s all working out fine.

    I think “PHP as a toolset” is as hard to categorise as “a web application”. Sorry Harry, but I think your attempts to figure out what PHP actually is are doomed to failure :).

    yours, Marcus

  • figure out what PHP actually is are doomed to failure

    Yeah you’re probably right.

    Actually wasn’t trying to work that out here but rather looking at (in simplistic terms) what “works” when it comes to writing code with PHP.

    app. layer on top of that, we have a pretty thick domain layer. That layer is heavily OO.

    We sometimes feel we are pushing PHP pretty hard, but guess what? So far it’s all working out fine.

    Think you may be a special case – am I right in saying you’ve invested alot of time in building libraries to make this possible? That’s compared to, say, writing a blog with just vanilla PHP.

  • – am I right in saying you’ve invested alot of time in building libraries to make this possible?

    Yes, but not all of them are in PHP. We have Perl tools, XSLT and various scripts wrapped up in PHP classes. Also most (except the persistence layer and the deployment and test tools) are pretty application specific. It is more of a technical domain library than anything general purpose. The so called libraries are just more code to us.

    Really the only difference is in the level of complexity below the web page. Those few web pages are still in script form, but even here we are going to look at Mojavi to get them under more control.

    I think any style is possible. Sorry to disagree ;).

    yours, Marcus

  • At some point think there needs to be a blog on “Things you shouldn’t do with PHP” ;) There’s some crazy projects out there like OpenGL for PHP. Not sure if implementing a full domain model fits – perhaps it does if you believe Rasmus’s point of view on PHP.

  • Manolo G

    Not sure if implementing a full domain model fits – perhaps it does if you believe Rasmus’s point of view on PHP

    I believe that you should always try to model the heart of your application as a domain model, whenever is posible.

    PHP has proven myself so many times that even pretty crazy things like AOP are feasible, but for some reason I always find myself dying of thirst when the water is one inch away.

    I am experimenting with object-relational mapping in PHP and I have been succesful so far. I am developing something like a Hibernate (Java) clone for PHP 4, meaning that you can work with plain objects as long as you do the mapping right, but when I reconstruct an object graph from the database I am facing this problem with associations:

    class A{
    var $B;

    class B{
    var $A;
    var $nombre;

    $B = new B();
    $B->nombre = 'Hi, I am B';
    $A = new A();

    $B->A = &$A;
    $A->B = &$B; // bidirectional association (AKA circular reference)

    if($B->A===$A) // Fatal error.. nesting level too deep
    echo 'equal';

    Which turns down my goal to make my tool transparent to the developer and forces me to use some function like ORMequal($obj1,$obj2) to test for identity. I discovered later in the manual that object comparison is based on attribute values and NOT in references which doesn’t happen in a complete OO language.

    Anyway, from my experience I think in the actual state of technology PHP is such a great tool that allows you to quickly hack a simple webapp in minutes or take your time and develop enterprise ready services that will run in multiplatform environments and you can certainly bet some money for. It all depends in the time and experience you have to build the program.

  • ausurt

    Maybe that list might just be too long, but this depends on your stand point of what PHP should be doing. I think its the best language available to use on the net, but I dont think I would be using PHP GTK to create applications for people to use on their desktop, instead id be using a medium in between that communicates between the two. But it doesnt really matter if the projects dont turn out to be used as much as others, I still go “wow”, even if thats the only time I look at it. If someone puts in the effort to make such projects I think they should be congragulated.

Get the latest in Front-end, once a week, for free.