Elegant PHP Architectures?

akweboa164 asks: "I work as a lone developer creating small to medium scale PHP/MySQL websites for different clients. I have been doing this for about two years now, and have tried different things as far as website layout/architecture goes. With sites that use the fusebox architecture, front controller (thanks J2EE), N-tier, to having a simple 'include(config.php);' line at the top of every file, I am left with the feeling that all of the sites I have created are 50% elegance, and 50% nasty kludge. I am left with a sinking feeling because I know that they could be better, but I lack to expertise and experience to make them that way. I am looking for overall architecture that is open and fits within the constraints of PHP (ie. relying little on OO) and separates logic, makes updates easy, etc. I wanted to ask Slashdot's crowd of web developers what their most elegant code layout/design web solutions were, and what advice would you dish out to new developers, as well as seasoned professionals."

Comments

Relying little on OO...?

[simon13]

Quote:
I am looking for overall architecture that is open and fits within the constraints of PHP (ie. relying little on OO)...

Why relying little on OO? What's wrong with PHPs classes and objects?

Simon.
(a semi-newbie to PHP)

Re:Relying little on OO...?

[ptaff]

The model is still incomplete.

PHP5 promises great features, but PHP4 still lacks lots of OO concepts.

• No private/protected/public
• No static class attributes
• No abstract classes nor interfaces
• No function overloading
• Still experimental aggregation/composition

You can do OO-like stuff without the points above but at the expense of no encapsulation and ugly hacks.

Some elegant constructs are hard to achieve in PHP, a statement like this (in java) would have to be dereferenced one by one by hand:

object.person.bart_simpson.say("Bite Me!");

Somebody who has already done some OOP would be able to find workarounds but PHP would not be a good way for a newbie to learn OOP.

Re:Relying little on OO...?

[rempelos]

PHP5 promises great features, but PHP4 still lacks lots of OO concepts.

• No private/protected/public
• No static class attributes
• No abstract classes nor interfaces
• No function overloading
• Still experimental aggregation/composition

ok PHP hasn't the great OO features that other languages have (like java), but most of the PHP programs are written by one programmer and for producing HTML code which isn't the same thing as developing huge projects in an enterprise logic.

You can do OO-like stuff without the points above but at the expense of no encapsulation and ugly hacks.

OO is all about encapsulating and ugly hacks are made because of ugly designs. There is a tremendous advantage when using the OO features of PHP, for example you can create a class that encapsulates the database connection and all operations to it.

A very good example that demonstrates what you can do with the OO features of PHP is PHPlib, it has everything the original poster asks except it's based on OOP.

Dude, don't worry about it.

[Anonymous Coward]

95% of all Internet endeavors go bust within the first 2 years, chances are, you won't have to touch the code again. The other 5% are all porn sites, in which case, you don't want to touch the code to begin with or maybe you do... Well dude, use a front controller like Jakarta Struts.

web apps just aren't there yet

[MikeRepass]

I feel ya.

Personally, I deal with different technologies, using ASP.NET (the horror!) to craft a rather random assortment of inhouse management tools for an IT organization, but many of the issues we face are the same. From ye olde days of ASP 3.0 with the ugliness of "includes" to a modular, n-tier approach, I'm always left with an unshakeable feeling that things could have been done better. The kludge that is modern web application interface (that is to say, HTML, J(ava)Script, etc) are too scattered and poorly supported to make anything approaching an "elegant" web application. (Btw, I'd love to be proved wrong here ...).

Here are the few suggestions I have which I can confidently say have improved my productivity. There probably the same things that everyone has come across, but maybe if I throw them out here I can invite some discussion.

Separate the task-at-hand and its implementation logic from the presentation layer. For instance, I normally write all of my business logic and database code as if it were just going to be an entirely separate library, and not particularly targetted towards web dev. This not only enforces solid library design principles, but allows me to debug and test using simple command line interfaces to the library. Approaching your code from a new direction (in this case simple user apps) frequently opens up entirely new ideas and perspectives. Once you've done this, the majority of your "behind-the-scenes" web code can just be a wrapper for this library, and then all you have left is the presentation logic. This has helped me immensely in the areas of scalability/integration and portability.

Second, never ever do any cosmetic presentation work until you're absolutely sure you have a beta (or better) quality base of business logic you're prepared to stand by. Adding the presentation logic to a web app too early is sort of like munging in command line options to a good ole console app: if done improperly, things quickly get out of hand and you have to code in more global scope hacks than you'd like to admit. Personally, after many bad experiences with this problem, I do *all* my testing on blatantly ugly hand-crafted html pages until I'm sure I've got things right.

Third, don't focus on a "page" as a discrete, targeted development object. Rather, the actual pages should be afterthoughts. Try to engineer solid "user-interface" components, and then plan on the final web pages as simple composites of these components. I estimate that, when I sketch out my initial concept of the pages and interface layer of a web app, more than 50% of the various tasks presented to the user will change drastically in scope before I'm even done developing. You realize that certain tasks just aren't needed, certain things are inconvenient, etc and using a component model to the presentation layer helps reconfiguring immensely. One of the biggest frustrations with web application is that, when different ideas are flying through your mind, its difficult to figure out all that must be coded in order to test them out. You think, "hmm this might work!" and find yourself having to chase down random bugs and make changes in five different files just to get a prototype working. Using a component model helps quite a bit in this department.

In terms of architecture, the only vaguely successful model I've come across is (once you've got a solid library backing you up...) model your application as a set of distinct user tasks. Allow each task to develop independently, and the step back and look at where the overlap is and what components are a good candidate for integration. Taking things on a task-by-task basis at the beginning helps immensely in bug detection also, because you're only focusing on one coherent progression of logic at a time.

I realize that most of this is probably old news to any qualified web dev, but this is the stuff I have to continually force myself to do after two years in the biz, so perhaps it is of some use. Any comments, suggestions, rebuttals, etc I'd be glad to hear.

Mike

Re:web apps just aren't there yet

[Tablizer]

The kludge that is modern web application interface (that is to say, HTML, J(ava)Script, etc) are too scattered and poorly supported to make anything approaching an "elegant" web application.

Agreed. HTML+DOM+JavaScript is optimized for e-brochures, and not business forms. Web stuff gets tricky when one tries to make HTML forms behave like real GUI's.

What we need *is* real GUI's over HTTP. Candidates include XWT, XUL, and SCGUI (my pet fav).

However, if we must live with HTML+DOM+JS for now, then my advice is to try to emulate GUI's using a persistent server-side copy ("view") of a web form. Echo this back to the client after updating it. Whether this "view" is stored in RDBMS or objects is a personal preference that I won't go into here.

For more on my opinions on this, see:

http://geocities.com/tablizer/webstif.htm

Some suggestions

[Alpha27]

I like PHP alot for web development. I found it easier and less to code when compared to perl (I've done both for 3 years each). You've made a good choice with it. I haven't tried python, but i do hear good things about it.

One important advice I would give is.... learn from your repetition. Meaning.. if you see that you code very similar functions or code segments that very ever so slightly, maybe there's a new function in there, that could emcompass them all.

For example:

• writing tables: I wrote a class to take an array of array, and spit out a table structure. Beats having to write echo statements with td tags, mixed with variables.
• simple dababase functions: I've knocked out a number of lines using simple code that does the same 3 steps into one function.
• object oriented code: definitely helps out.
• apply theory/concepts to work: I've seen the Model/view/controller example applied to non java languages. As well you can use cool things like XML/XSLT to handle data/presentation, there by allowing for multiple display formats.

some times the elegance is in the hack. I rewrote an art project at the company I work for, using our product for the front end, and php for the backend within 6 hours. He originally wrote his from concept to product in a year. Not bragging, just saying. =)

Look into some of the templating engines, like smarty.php.net, it's srecommended at a number of sites (I haven't used it yet), but it will allow for cleaner code, and that's what is important. Accessing code you can easily fix, and change the presentation when needed.

My PHP tips

[Imperator]

I don't claim to be an expert PHP developer, but I have spent a fair amount of time with it. Here's what I've found works:

• Every file includes base.inc.
• base.inc includes a config file based on the hostname and port--this is to allow you to use the same code to run both testing and production servers. These config files are where you keep stuff like the directories in which to store files, the database config, and so on.
• Use PEAR as much as you can. In particular, use PEAR::DB. Since you probably use the DB in every request, open it up in base.inc and store it in a global. Also, you never know when you'll switch to a different RDBMS, and if you have to modify every single call...
• On that note, use PHP OO to abstract away the DB. Do it logically, not "one class per table". This way, when you change the database or even just the schema, only the library files need to change. If it's a big multi-user project, write regression tests.
• If you're using the Zend Optimizer or a similar bytecode cache, go ahead and include all the library files from base.inc so you never have to worry about doing that.
• Use CVS. Even if it's just you.
• Use a good template system like Smarty. Just because PHP lets you mix code with HTML doesn't mean it's a good idea.
• Write your own classes to handle any common task, even for something as simple as getCgiVar().
• Keep the DB schema in one file so it's easy to read and modify.

Re:My PHP tips

[Blaze74]

Take what the above poster said, but use base.php instead of base.inc. Using .inc files is asking for trouble when you deploy it on a server that does not restrict access to files with a .inc extension and someone decides to look at database_passwords.inc

Re:My PHP tips

[FryGuy1013]

unless you have register_globals turned on..

if (!isdefined("real")) die("hacker");

and

define("real", 42);

would be better.

Just Another Hacker's Advice

[eddy the lip]

(Sorry about the code formatting. Slashdot's messing with it, and dinner's on, so no time to futz with it).

I make few claims to writing elegant PHP, and I'll generally sacrifice a few extra CPU cycles if it will save programming time. I have yet to run into a situation, even on high traffic sites, where this isn't a worthwhile tradeoff, as long as you're not writing horrendously inefficient code. If there are bottlenecks, I'll look to sections of code that are getting hit a lot and optimize on that level. You might have guessed that I'll take the performance hit and use objects if I feel like it will make my job easier. There are fancy names for most of this stuff, but never mind those for now.

What I do depends largely on the scope of the project, but there is one rule that I follow without exception. Nothing goes into the page that's being displayed but control flow statements and variable output. No assignment, no (god forbid) database calls, nuthin'.

For simple, one page, this-will-be-dead-in-a-year stuff, I put this at the top of the page:

// index.php
<?php
preg_match('/\/([^\/]*)\.php/ ', $PHP_SELF, $matches);
$code_file = $matches[1] . '_code.php';
require($code_file);
?>

and all the work goes into index_code.php. Beyond that, for this level of work, I don't worry much about elegance beyond the usual rules of breaking discrete bits into functions rather than allowing everything to string on for screens and screens of scrolling. This is mostly for my own sanity.

if($foo) { doStuff(); } else { doSomethingElse(); }

is much easier to make sense of than if all the work is sitting in between those conditionals.

For larger applications, I use a config file that contains any configuration I might need. Again, as little logic as possible. This is likely to be shared site-wide. An initialization file, also often shared, contains any beginning work that might need to be done. Checking to see if variables should be pulled from $HTTP_POST_VARS or $_VARS, calls to authentication routines if necessary, etc.

This will be driven from one file who's job is to figure out what needs to be done, and dispatch the work accordingly. Again, depending on scale, this may also contain common footers and headers. For bigger projects, all this does is dispatch the calls, and HTML is pulled from a template file, with content being inserted into it.

The dispatcher will call the appropriate code file and a matching file that contains the HTML and any required control flow stuff (as above) for content display. The code file doesn't contain anything "deep." Anything remotely heavy is done with classes included from a lib/ directory.

This structure gives the following benefits:

• one place for site (or project) wide look and feel changes
• easily findable files for the designers to mess with. Ours are more than capable of dealing with the occasion if or foreach
• heavy code in reusable classes, centrally located. One stop bug fixing.

One last note. I don't use a templating engine. Things like smarty are nice and all, but with a little discipline, you can achieve the same effect with no added complexity.

Seeing as the post has a zero flame content, I will add that nothing I do in PHP ever feels "elegant." For me, PHP is a pragmatic choice (widely available). The language itself (to me) has a cobbled-together feel. I'm sure that will change as it matures, but I find that things I do in PHP often have a cleaner feel in perl. I'm learning Java, and so far I'm getting the impression of language-elegance from it as well. On a purely aesthetic level, I think the language you chose has a strong impact on how elegant your solutions feel.

Re:what I do...

[brianlmoon]

And PLEASE, use PHP objects. Someday PHP will be a "good" programming language with good OO features, get used to what it has now.

I hope you are not implying to use objects for the sake of using objects. I use objects where they are needed. But in a language that is not bound to them, they are not needed all the time. I remember someone wanted to have a String class be part of PEAR. Why on earth do you need a string class in a language with such great string functions? I have seen object overkill and it is not a pretty thing.

Where do I use them? When I need to keep stuff "behind the curtain". We have a class to display large tabular data that we use. It is the right choice as we just call $report->addrow("data", "data"...); and the class keeps up with it all in vars for us and there is no mess.

So, use them where they are appropriate, is my advice.

Brian.
Phorum.org

Here's an elegant way out... Drop PHP

[Randolpho]

I have a wild suggestion. If you want elegant, kludge-free web applications, drop PHP. The very nature of server-page based programming (PHP, ASP, JSP, etc.), the very act of mingling your code with your markup is non-elegant. Unfortunately, there really isn't any way of separating the two in an elegant fashion, so you're sorta destined for a kludge somewhere, but there are better ways.

One kludge I rather dislike about nearly all server-side programming is the necessity of a connection to a relational database. Invariably, you must get into a lower level to get your data; often you are forced to write SQL for your data, and if your database is complex your queries can get pretty convoluted. There are tools to try to make that transparent, but the cure is often just as bad as the disease.

There are better ways, however. Zope, a web application platform based on the Python programming language, is my current favorite. The big feature that I like best about Zope, aside from the excellent builtin security framework (which is head and sholders above PHP, BTW), is the persistent object database -- with it, Zope can entirely eliminate the necessity of an external database. Not that you can't connect to an external database if you really feel like it; Zope has a built in connectivity API, and there are plugins for all your favorite relational databases.

Zope has many elegant means of managing your content, from your standard header-footer includes to context-based acquisition, to the many content management frameworks already built for you on top of Zope like Plone. Zope comes with two powerful templating languages if you don't like straight Python: DTML and Page Templates.

That said, there are drawbacks: Zope is its own server, so you have to find a hosting company that offers Zope if you don't maintain your own servers. Zope.org lists a few free hosts on the main page. Using the object database is great, but because it's transactional your disk space can quickly bloat if you running a website whose data changes frequently, like, say, a popular forum or blog.

As for the language changes... if you left perl for php because perl was ugly (and believe me, I agree), then you should try python. The language is elegance personified. It's a scripting language, so it lacks the performance of Java or C++ for computation-oriented stuff, but the stuff it does, and the simplicity! Often I've seen three short lines of Python code take tens of lines of Java code to accomplish the same task. Python is so readable you rarely need to comment your code if your variable names are well named. It's also fully object oriented, but if you don't like OO for some odd reason, you can do your stuff with just functions.

Wow... what started off as just a few lines turned into a novel. Now I'm all tired and stuff. Can you tell I really like Zope and Python? :)

Designed urls, a cache, templating...

[King of the World]

Design your urls so that they're content based, and not implementation based, so where possible hide PHP from the user. Hide filename extensions from the user unless they need them. Use slashes to show content hierarchy (eg. domain.com/story/2003/6/4/ rather than domain.com/story.php?year=2003&month=6&day=4). The HTTP GET key=value pairs should be avoided where possible, unless there is no hierarchy or many items. You'll probably need url rewriting for this.

The url should pass to a script that checks the cache, and obviously request a fresh copy if it needs it.

The backend architecture depends on the app. PHP is usually for the web, and elegant architecture for HTML involves themes. Here you have three options,

1. build the page up as a string,
2. build it up using a templating language's OO where you have table objects, and you attach row objects, which contain cell objects (similar to ASP.NET)
3. build it up using XML (my favourite)

Building the page as a string means that it's easier to have HTML flaws caused by one module affecting another (as PHPNuke has found). However, this is the most flexible method, if you want bizarre HTML. Dealing with strings is the older way of doing it, and I don't have much good to say about it this. In many templating engines the goal is to try and invent a simpler syntax, and then 2 years later they've implemented their own programming language. There is no such thing as simple logic when it comes to layout and HTML, and these "simple" languages often have little thought put into them, and don't allow reuse, or extensions via modules. They often end up being hacks. There are some mature examples that have solved this problem (PHP Smarty, who have simply implemented PHP in a templating language!) and these may be suitable.

Building the page using an OO means that you have a IMAGE object that has properties such as ALT text. That body object can only have certain other objects attached. You have a programatic way of dealing with a page, and you're not limited to a templating software's mini-language. However, you'll probably need to be a programmer to change the themes so you can't hand the code off to designers. It's the ASP.NET model, although there are better ways of doing it.

Building up a page in XML is elegant, in that you can refer to an XML node and attach/remove branches. You can pass nodes to PHP modules and let them attach content, knowing that all tags will be closed. You can enforce a schema/dtd on your content, and maintain a high-level language up until the moment that you publish to HTML, probably using XSL-T to theme the page.

The XML method is the best balance, IMO. XSL-T is very suited to formatting HTML, and if you want you can go to PDF via XSL-FO quite easily. I recommend building an XML file like XHTML 2.0 and then XSLTing that down to XHTML1/HTML for the cache.

As for how you handle the data, I don't really care. Personally I'm waiting for PHP5 to bother OOing my PHP.

My main gripe with PHP is that not enough is included in the default build that comes with distros and is offered for windows download. So that the generic hosts don't have the feature you need. The people who care about trim build know how to trim it more than those who don't care and end up avoiding features.

I was trying to respond earlier, but Slashdot still haven't unblocked a large...large range of IPs from posting (presumably it's not something I've done, as this account is available). Don't even bother emailing them folks, my 3 emails haven't got one answer :(

Re:Java View/Model/Controller

[amorico]

This makes so little sense that I can only assume that Ms. Coulter is laughing her butt off at the moderators.

There is no Java MVC for the web. You either roll your own or use Struts or Webwork or Maverick et al. MVC is a design pattern, which was correctly stated.

That, however, was the extent of any correctness. The Model is the data, which in her case would be the MySQL held data. The view would be a generated html page, JSP, Velocity Template, XML/XSLT pipeline, or whatever display technology you would use. The controller would be something that receives requests from a web browser and then decides what action to take (pull data from a database, massage it, return it, and show a results page). Accessing the data is handled by Data access objects or delegates.

If you don't know what in tarnation someone is talking about, don't moderate it down or up, just leave it.

I am going to start using that line at work though. "If we use java this way we will be akin to apple!"