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)
I have always favored Java's architecture. It is a very organized and powerful solution. By combining Java with MySQL, one can implement the View/Model/Controller design pattern in a web site. The Java applet and web documents will function as the View whereas MySQL implements the Model and the Controller will be the interface code for MySQL. Using Java in this way will lead to solid code akin to Apple.
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.
...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!
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
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:
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.
Why avoid OOP? PHP supports classes.
Granted, it isn't Java, but that isn't any reason to avoid them altogether or to avoid the tremendous amount of benefit that can be obtained from one.
jason@php.us
My
Limekiller
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:
Gates' Law: Every 18 months, the speed of software halves.
OOP support in PHP is currently very low. Performences are horrible but I use it anyway. Most of the time, performences are not a must so go for clean code. PHP5 will be great thought.
I usually design an object layer under the website to access the data (read/write). All validations are done there. All that is left afterwards is to plu a user interface on top.
(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:
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 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.
This is the voice of World Control. I bring you Peace.
I am looking for "best methods" for mySQL/PHP, after hacking away for a year or so now building web apps, i want to do it the right away, using OOP where appropriate, and making using of proper formatting and commenting.
Please, show me some really well done mySQL/PHP stuff, who is setting the trends?
Cloud City Digital: DVD Production at its cheapest/finest
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?
I use classes extensively in PHP, as well as PEAR whenever possible. It's slow sometimes and doesn't feel as elegant as Perl's add-on modules (yes I just used "elegant" and "Perl" in a sentence, I've done some nice stuff with mod_perl and XML) but it makes your code a lot cleaner.
Separating code and presentation: well we all should realize 100% separation is impossible, but you should try as much as possible. I've been having good luck with Smarty. Basically you write a bunch of PHP code that computes all the parts of your page, then you send all that off to template code that generates your final page. This is a good system, even if you don't use Smarty (it could just be two different PHP scripts, one is a model, the other a view/controller).
Basically you write your code, then you do the presentation, then you go back and adjust the code, then you adjust the presentation, after a few iterations it stabilizes nicely.
Another interesting thing about Smarty: the author(s) of Smarty inadvertantly created a new programming language inside Smarty using Smarty tags, which isn't PHP, so you have this weird feeling of programming in two different languages... and it turns out to be a great way to keep the two realms separate (at least for me).
I would recommend trying this approach, if you don't use Smarty, you could use PHP and XSLT: PHP code that generates very basic XML containing the data you want to display, and then a Perl or PHP or whatever script that just applies XSLT and then sends the HTML to the browser.
I think this "two-stage, two-languages" approach has helped me keep everything separate in my mind, give it a go.
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've been checking out ez systems. http://www.ez.no/
It's a cms system, written in object oriented php, and seems pretty comprehensive.
I'm holding out for a good server-side open source ecmascript interpreter(maybe mono?) with built in support for xml(e4x).
Good luck!
my other sig sucks less
The only elegant PHP layout...Is when it is rewritten in Perl
Cue stock footage of explosion at the punctuation factory...fade to black...
You'll have that sometimes...
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
How on earth is Perl elegant?
I think you misunderstood elegant for unreasonably complicated and illogical.
And what is it with elsif? If you have a grudge against the e, trying to take it out of every situation possible, can you please keep this issue locked up inside?
PHP is just a better language in many ways. The only downfall of that is that bad programmers realize that, and learn to write programs before they learn to write good programs.
- - - - - - -
Orppf urp mf y.ppcxn. yflcbi otcnnov C am yflcbi yr n.apb Ekrpatv (Dvorak -> Qwerty)
Using PHP objects and the State Machine concept, I have been doing some things I think are unique, or at the very least interesting.
I am unable to send you to a specific site, since the bulk of my development has been for internal sites, developer/qa tools and so on. I can however say that taking this approach has made modifying my applications significantly easier.
I would be happy to talk further with this in email. I can be reached at the email address listed in my profile if anyone wants examples.
best web host ever
Check out phplib. I used it a lot back in the days when I was a php monkey :) Really loved it. I fumbled a lot with the templates implementation, which I didn't really like, anyway, any sane person would use php's xslt functions for that now.
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,
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 :(
--Giving to trolls for the benefit of us all
Whenever a new user connects:
r _profile();;
make_secure_connection();
do_login();
get_use
do
{
display_menu();
}
while(do_stuff(get_choice()))
do_logout();
break_connection();
I just wish - things could be done so easily on the web. Most of the web sites that I'm developing could very easily have been console apps. But I'm stuck with PHP and tousands of $ signs that come with it.
Well, I've tried a lot to separate Business Logic from Presentation Logic - but it just doesnt happen, even though each php script of mine has:
include_once("common_funcs.php");
right at the top.
Though PHP aint that bad - I wish there was a better way to do stuff. Probably it's got to do with the statelessness of the HTTP protocol.
Have you considered building yourself a controller like Jakarta Struts, in PHP? I haven't heard of one, but that might clean up your problems. With that, you can place a lot of "use this function in this page" logic in XML files so that it keeps your code clean. That would be some work, I guess, converting Struts to PHP, but not altogether undoable. You will probably need to make use of mod_rewrite.
Daniel
Carpe Diem
Everytime I use PHP I end up feeling dirty. Mixing the code and the presentation is just not the right thing to do. Content/View/Model is as close as I can tell to being the right thing. I personally have had great experiences with Apache PageKit and you get to use perl. In addition I'm rolling my own system using Python and Albatross. But PHP? Shudder.
that's what the include path is for
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
I use a neat Apache rewriting trick
/index.php [T=application/x-httpd-php,L]
.html is not in the document_root then index.php get's called instead and you can use the $_SERVER['REQUEST_URI'] to see what page was required.
d _M anagement_Systems/York/
o n= Graduate_Jobs&job_section=IT_and_Management_System s&area=York
RewriteCond %{REQUEST_FILENAME} !-s
RewriteRule ^(.*\.html$|.*/$)
that way when a request for a page that ends in
the world is an easier place when
http://www.thebigchoice.com/Graduate_Jobs/IT_an
is the URI instead of
http://www.thebigchoice.com/show_jobs.php?secti
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
You could try SSTP...it's a generalized layout engine written in PHP. It's very simple to work with, since it's designed for retrofitting a previous website with a layout. Just generate a simple HTML page and run it through the SSTP interpreter, which will apply the template and everything. It's not as fast as I'd like, but it works well and it has a cache if you want it.
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 also been programming in PHP for some time. I've developed a rather good class library which I always use. I do everything template based and all my database stuff (except writing the sql queries themselves) are object oriented.
:)
Even with all this, I feel I'm programming faster, but still I can't get anything architected properly. I've examined hundreds of open source PHP classes and apps (freshmeat & phpclasses), but none of them really use a good architecture.
I'm beginning to feel like it's not possible to write well architected apps in PHP.
I'm a very experienced delphi programmer, also, and doing good architecture is a lot easier in a non-request based development.
Since everything always has to be loaded and parsed in each and every request, I'm beginning to feel you really CAN'T create a good structure/architecture in a request based world like php. Everything always ends up dirty (at least in some areas).
I wish I was wrong, and I wish some of the comments above had disproved this, but they haven't. Actually, even though I don't want to start a flamewar, I really just don't think most PHP programmers know what a good architecture feels like, and that's mirrored in the way the comments above sound, even though some of them claim they have good architecture. Sorry.
We need a good book on this subject
I'm a reasonably experienced Java developer (4 years). We're mostly creating J2EE applications at my work.
... they all make developing a lot easier.
;)
:)) have when writing Java code.
Recently I had to work in PHP as well; a friend of mine wanted a small website. It was quite a change!
I know Java has its drawbacks, but the tooling is becoming really good: Eclipse, code beautifiers, Javadoc, Junit, StrutsTestCases, Hibernate
Tooling for PHP is another matter. There are editors, there are Eclipse plugins, but nowhere near the level of Java (or, of course, Visual Studio for that matter). It seems like all the tools are just a bit less mature (perhaps with the exception of database-access layers, there are quite good ones available). A point where PHP beats Java is of course deployment: simply change the source file, reload the page, and your application is deployed. That takes a bit longer in Java
However, tooling isn't the most important thing for a good system: the design is what really matters. This is not made easier by the lack of decent OO functionality of PHP. My approach was to stick with the 'Struts-way' as much as possible.
There's a reasonable Struts-replacement (Phrame), which works pretty neat with the template engine Smarty.
The project worked well -- but I'm happy to be back at Java. Somehow programming in PHP felt a bit 'ugly'. Although the code is quite readable, and the application works nicely, I don't have the same proud feeling I (sometimes
Don't know if it's an option, but I saw quite decently priced Java hosting: http://www.4java.ca/ (no personal experience with them though).
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 - ^_^
I agree very much with Randolpho's post. Ditch PHP if you really want an elegent architecture. If you really need to stick with PHP, try out Midgard. Otherwise, you really ought to at least look at the alternatives. Zope and OpenACS are probably the best open source web application systems/environments/architectures, whatever you want to call it. I prefer OpenACS (there's just something about using a system that was built primarily by highly intelligent MIT and CalTech alumni...).
OpenACS is based on AOLServer (probably the best, and first application-oriented web server out there, which was GPL'd by AOL thanks to Phil Greenspun's nagging. it's multi-threaded, it has database pooling, a healthy set of modules/plugins, and a wonderful community.), Tcl (you'll get used to it, really ;), and either Oracle or PostgreSQL. Thought it was designed for use with Oracle, and was ported to PostgreSQL, the architecture in OpenACS permits you to easily swap in support for other databases. Though, you'd have an extremely tough time getting it to work in MySQL as it relies on numerous high-end and complex relational databases features, most of which MySQL does not support.
OpenACS is highly modular, built entirely out of smaller packages, with its own package management system. There is a core package, the ACS Kernel, ACS Tcl (which contains most of the utility code, etc.), and there are various packages built on top of that which provide both specific application functionality, but also services that other packages can use. The documentation is built into the code and is available online in every OpenACS installation. Higher up packages include web page creation, bulletin board systems, blogging, content management, etc. You can "mount" these packages at various locations in the site map for your web site / application. E.g., you could mount an instance of the bulletin board at mysite.com/forum, and add a second one at mysite.com/techsupport. You can create subsites, such as mysite.com/internal/. There is an extensive and incredibly powerful permissions system so you can completely control access to every part of your system. There is also a built-in templating system which provides a simple separation between logic and display code, as well as theming capabilities.
I'm sure there's a lot that I've neglected to mention here. But I think you can get the point. OpenACS is a very mature platform that's be in development and production for many years now (hell, take a look at what Ars Digita was able to accomplish, they were making millions selling this system, and they gave the code away for free under the GPL). Don't take my word for it, go to the website and read about it. The only drawback to it that I see is that it does have a high learning curve. It took me a few months of reading and experimenting with it to really understand how the system works, but it's definitely worth it. There are a few hosting providers out there (Acorn Hosting and Zill.net) that offer affordable hosting packages, but it's also easy to setup your own server. OpenACS also has the ability to run multiple server boxes in a load balanced environment, so if you need to scale out, you can. Oh yeah, this is also a descendant of the same ACS system that RedHat's Enterprise Applications are descended from (RedHat got that technology when they bought the remains of ArsDigita.
Gabriel Ricard
[disclaimer: I'm a Drupal contributor] ;) cleanliness. /. home and withstands the load. I use Drupal to power different sites, from personal blogs to corporate intranets, and plan to use it as a base for other completely different projects.
Drupal is a CMS which doesn't use the OO features of PHP, but has nonetheless an OO design: for example all content is a "node", and you can "subclass" a node getting a story, an image, a forum topic etc.
It uses hooks so it can be expanded easily; it has both themes a-la *nuke and templates. Of course it has a good user management system.
The core is maintained by few people (not me) in a very strict, almost maniacal
It's fast and powers sites like Kerneltrap which sometimes is on
It also has a very active community.
Of course it has its own faults and deficiencies, but we are working to fix them.
Here is a recent review of Drupal.
...and Python.
PHP4 is problematic archectecture for what you ask. PHP makes profoundly stupid architecutral blunders like lack of namespaces for library functions, which makes it hard for someone else reading your code to determine where function X came from? Inline includes.evals of code are bad, bad, bad too.
You really want a MVC-ish sort of seperation of concerns, I suppose? Zope will do this: XHTML or XML Zope Page Templates, which are valid XML (code via attributes and XML namespaces) using the TAL namespace. Also, ZPTs will allow you to put mockup in your templates and strip out at runtime. In Zope, page templates (view) use simple Python scripts or ZSQL methods for glue logic (controller), and support either content objects developed as low-level Python Products (model) and stored in the object database, or alternately, just have content stored in every RDB you could think of. Best of all, Zope uses Python, which is a much more clean language.
I've been working with PHP for a while, now (not because I like the language much, but becaust it's what's available, and sometimes because it has lots of useful built-in functions :) and have come to the conclusion that YOU CAN'T WRITE ELEGANT PHP!
:)
/quite/ so kludgy...
I mean, first of all, how are you even going to load your libraries? Say you have a directory that contains your library of code. Call it "lib/TOGoS" (that's what mine is called). Now, say I have 'lib/TOGoS/TSDFEntrySet.php' and 'lib/TOGoS/TSDFParser.php'. TSDFEntrySet relies on TSDFParser, so it does a "require_once ('TOGoS/TSDFParser.php');" at the top. But that won't work because depending on where your script is, your library will always be in a different place! If you have access to PHP's library directory, you can put your libraries in there. But often you won't have access to that. Now you could solve this by putting in absolute paths for all your libraries (yuck) or by making a global variable that tells where the library directory is (ewww), but I've found that the most elegant (least kludgy) way to get around this particular annoyance is to CD into the 'lib' directory and require files from there (ugh). That way at least your libraries don't need to worry about it!
I've been spoiled by Ruby and the way you can just do "$: << 'lib'"
Anyway, after tearing apart and re-writing all my scripts about 3 times, I think I'm finally starting to find a way to do this that doesn't seem
<?php
$apath_docroot = '../../';
require_once ($apath_docroot.'main.php');
trequire_once ($lpath_lib, 'TOGoS/WebPC/MessageBoard.php');
$page->output_head();
$messageboard = new TOGoS_WebPC_MessageBoard('entries/');
$messageboa rd->load();
$messageboard->output_page();
$page->output_foot();
?>
Which needs a bit of explaining...
the $apath_docroot global variable is the 'apparent' (as in to the web browser) path to the document root. This is used by the $page object, for example, to write links to style sheets or the site index or whatever. My 'main.php' is kind of a site-wide configuration file. It creates the 'trequire_once' function (which 'CD's into the directory specified by the first param and requires the file specified by the second), and sets $lpath_lib (local path to lib, as opposed to apparent) and $page (an object that helps me build my pages). Now in order to do all that, it needs to know the path to document root. Usually this is the same as $apath_docroot, so it can just use that, but in case it isn't (because this directory is Aliased or whatever), I'll also specify $lpath_docroot before requiring 'main.php'.
One problem I seem to have a lot (not necessarily a problem with PHP, but it does seem to come up more with server-side web programming) is that I choose the wrong things for objects to do. Here's a hint: It's usually a bad idea to make an object responsible for loading itself or displaying itself. When I do this I end up running into problems like subclassing a class to display itself differently, but then when I retrieve it from somewhere ($entryset->get_entry(5), for example), it'll not know anything about my subclassing and give me the original object. So it seems that the best way to go about this is to have one object whose job it is to interact with the user, and one object whose job it is to load and save data from files or from a database. When you create the front-end object, give it a reference to the backend object, and all it has to know is $backend->get_entry_list() and $backend->get_entry(id) The backend'll most likely return an associative array. And it can use a DBMS, a directory full of text files, or an XML document to store the data. The front end doesn't need to care!
Also, note how I have a 'WebPC' subdirectory under my personal library directory. This directory contains all the code that deals with the web inter
Duct tape, XML, democracy: Not doing the job? Use more.
I have made a system which automatically stores data objects to a MySQL database. Each class gets its own table, and each subclass also gets its own (where it stores its particular data). Links between objects are presented as references to object ID's, and you can load and save any object by this ID.
:-) slogan "Now you know where to stick your data" :-)
There are one or two hackish and/ or purely practical things about this solution, but you can write fast and elegant PHP code with it (which is why it was made -- I too found PHP lacking on this). The database is MySQL but a port to any other database would be possible without having to alter your scripts -- they remain database independent.
The biggest problem with this code is its "internal" state, e.g. not being known by the world, not really being compared to other systems, and lacking support and H-Q documentation.
But if you're interested, version 1.0 is available from here: http://pflipp.nl.eu.org/software/sssi/
(The product is called "Achterwerk", which means "rear end". Which is why we have our (trademarked
"We can confirm that Debian does *not* ship the version with the trojan horse. Our version predates it." [CA-2002-28]
One strategy I use is to write ultra-generic PHP classes that handle generic Web interactions -- a SinglePageVisit, a OneStepValidatedTask, a TwoStepValidatedTask, etc. Those classes implement a basic logic -- e.g., the OneStepValidatedTask displays a form, then validates the user input, then either displays the form again with error messages or executes the SuccessAction.
Then I use composition or inheritance to extend these generic concepts into specific applications. (To continue my example, the child class for OneStepValidatedTask would define what exactly SuccessAction does.)
This approach has been useful so far.
I've used Zope and PHP, and they both have their strengths and weaknesses.
:)
Zope's documentation is painfully, hopelessly bad. That makes difficult to move to more challenging projects.
I love PHP's online manual. The inline comments left by other users frequently help me figure out some odd error I'm having.
I'd go on and on here, but I'm really supposed to be paying attention to my lecture here
Froggie!
I agree, I've developed quite a lot in Perl, and multi-tiered functions and modules (with clear, obvious and documented pruposes) are the way to go.
e =>$username,retur n=>"realname");
:(
I'd never want to embed SQL/LDAP/etc calls in a page and I always cringe when I see that. I'd rather have a function:
get_user_realname($username);
which might call:
db_connect();
db_get_data(key=>'username',valu
db_close();
return($realname);
(and then I'd right db_connect, db_get_data, db_close as my own functions so I can easily change the modules I use to connect to the DB at a later date).
This way it's much easier to do elegant error handling and to optimise code (as you can easily identify bottle necks).
Non structured code is a maintenance nightware and something done by bad web developers who are either incompotent or would rather they look good for the boss than spend time doing something properly (and ultimately doing the Right Thing for their employer in the long run).
It think this is one of the problems of PHP - it's easy to use, but does not enforce any structure, so those with no design knowledge (or aptitude) can get stuck in and turn out nightmare FPOS software by the bucket load. You can do this with Perl too, but ultimately I think some of the additional complexities of Perl beat this out of most users after a while and they end up being better developers in the long run (because like it or not they end up learning things).
Ultimately however, some people are dumb-as-stump and won't ever be able to churn out sensible C/C++, Java, Perl, PHP or even VB.
Phrame has already been mentioned.
Eocene (Looks very promising)
php.MVC
These guys did a really good job of abstraction of the various significant parts of their app. A lot went into the database, and it allows for development of other systems with out much more PHP code. Multi-language is handled nicely.
ariadne.nuze.nl
Also, there is typo3.org... that is another interesting bit of code that basically allows you to use the template system, and it takes care of the rest.
--gabe
My approach to this has always been to provide a separate script that handles the logic required by a controller in an MVC methodology, but not to use include() or require(), but rather have it act alone, e.g.:
mysite.com/control/index.php
whereas in my apache config, the control script performs controller type logic (e.g. request parsing and handling, session initialization, parameter encapsulation, etc.) and then requires the PATH_INFO as the the model (e.g. an Action if you were using Struts). Use Smarty for your View tier, ad you have a complete MVC system.
http://wayback.sha-bang.com for a working implementation of this idea. Essentially, the result is that you should never have to call include('control.php'), but rather all the logic in control.php should be forced by the apache configuration and the controller logic.
Another thing I've implemented is that all of my "action" scripts have defined functions, e.g. a service() and init() function that are called by the controller script through a callback.
it's for machines
I T_ and_Management_Systems/
d _M anagement_Systems/York/
url's provide a context for the content
s'all about the page ranking
The search parameter order randomness is not unworkable, it already does that for the last two items
http://www.thebigchoice.com/Graduate_Jobs/York/
and
http://www.thebigchoice.com/Graduate_Jobs/IT_an
yield (almost) the same page (the url affects the H1 you see)
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter