Slashdot Mirror
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."
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)
...move to Common LISP. Paul Graham says that the problems you're having are because of the lack of expressiveness of your language. People don't write software; they write domain languages, dude!
Page-based approaches (PHP, JSP, etc.) don't really scale well. They are fine for a project consisting of a handful of "pages" but once you start dealing with 10, 20, 30 pages, the metaphor just crumbles and you need to start with a new type of design, like MVC. Unfortunately, I'm sort of cynical about the prospects of modeling interactive applications (face it, a lot of these web "sites" are really "applications") on a low level REST/HTTP protocol and think something new is needed like cURL. But in the real world, if you can refactor your application into MVC and use a page-based scripting (or templates ala Velocity, FreeMarker) for presentation only, that should scale better than pages. (i'm talking scaling in complexity, not load)
It's 10 PM. Do you know if you're un-American?
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
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?
"Times have not become more violent. They have just become more televised."
-Marilyn Manson
Imperator wrote:
There are some who would strongly disagree with you on this point. For some interesting arguments against templating systems written in PHP, check out this article at phpPatterns.
I've been designing PHP & CGI based online applications for a while and have come to primarily focus on one way of implementing any large scale PHP project, I haven't worked on to many smaller projects so don't know if this would be a good way to go or not.
I usually centralize the system initialization in a single file, ie index.php, system.php or core.php. This file usually performs the rudimentry stuff that all pages need, ie including config file, init database, calling authentication functions, and the basic theme display/theme stuff.
All of this is usually controlled by a serious of ojects, one for the database, authentication, and display itself are kinda the main objects, others may be implemented depending on the project.
After the system initializes itself and does the top level functions. The display object usually creates an object or includes a php file to handle this function. I usually have the system attempt to do this dynamicly based on a GET or POST value so modules can easily be added or removed.
This may not always be the best way to do it but works pretty well. It really makes it easy to add top level function to the over all system and the single file or object for actually performing system action are easily updated and can all be centralized, this create a much more module system.
I hope the third little piggy got mad cow - ^_^
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
Table-ized A.I.
Thanks, reading now...
Don't forget the CSS. By using overflow:auto on a fixed box you can make scrollbars, and emulate many types of layouts previously impossible without crummy old frames.
--Giving to trolls for the benefit of us all