Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
PHP Programming

Elegant PHP Architectures? 118

Posted by Cliff from the sublime-setups-for-beautiful-code dept.
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."
This discussion has been archived. No new comments can be posted.

Elegant PHP Architectures? More

Elegant PHP Architectures?

Comments Filter:

  • Relying little on OO...? (Score:3, Insightful)

    by simon13 ( 121780 ) <slashdot&simoneast,net> on Tuesday June 03, 2003 @09:16PM (#6111113) Homepage
    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...? (Score:5, Interesting)

      by ptaff ( 165113 ) on Tuesday June 03, 2003 @11:55PM (#6112022) Homepage
      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.
      • Actually the following:

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

        wouldn't need to be dereferenced by hand.

        However, this would:

        object->person()->bart_simpson()->say("Bi te Me!");

        Method calls that return an object can't be immediately dereferenced in the same statement. Those would have to be dereferenced one by one.

        But I know what you mean though. It sucks that you have to do that :)
        • Hmm... I find this a bad example anyway?

          From Object to Bart Simpson: that's a generalization/ specification, but the notation is more or less a class namespace thingy (either that, or an aggregation -- like System.out.println()).

          This stuff is more confusing than the average teacher's example :-)

      • 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-lik

        • 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.

          Let's say you want to use only one connexion handler in your database class (so that objects inheriting from it can use shared "insert" and "update" methods). What you'd do in a real OO language is to use a class attribute, shared by all your class instances.

          • Let's say you want to use only one connexion handler in your database class (so that objects inheriting from it can use shared "insert" and "update" methods).

            PHP uses persistent connections for both mysql and postgresql (which i know), so I don't need to use only one connection handler, PHP will automatically use the same db connection anyway

            These two examples are ugly, but only because of the language limitations.

            Nope, poor design again. And I think that you are still missing the point. The langu

          • in a real OO language is to use a class attribute

            kinda like a reference [php.net] to your database object, or any other object inheriting from it. Then to call $this->db->query(). You could possibly even just include() the db class and db::query() from your object as php will use the same mysql connection as the poster above mentioned.

            you have to use global variables

            Not always, thats just one way. Each update to PHP brings changes such as tighter variable types and enforcing the syntax more, imo its matur
    • Maybe this isn't *quite* what you want, but sounds close to your requirements. It also costs money....

      I love the product I'll mention, below. I'm not selling anything, either, but am just a "hooked" developer.... So, here goes.... (No flame wars, please.)

      I'd look at CodeCharge Studio at their http://www.codecharge.com/ [codecharge.com] web site. It generates excellent PHP, does excellent database and forms work, and lets you adapt the code it generates. It's also a full-blown IDE.

      Now, it DOES make heavy use of OO,
      • Now, it DOES make heavy use of OO, but I think it's still based on OpenSource API's....

        WTF does this mean? How is object orientation incompatible with open APIs? Do you know what you are talking about, or are you just a marketing idiot?

        • That's not what I meant. I was answering two *separate* points he had in his request. He wanted little use of OO, but strong use of OpenSource API's.

          Did you read my comments in the context of his request?

          In other words, this product does not address every goal he had, but many of the things he wanted are in there.
    • Why relying little on OO? What's wrong with PHPs classes and objects?

      At the risk of being modded down as a troll, frankly there is no objective open evidence that OOP is superior. All the cliches about reuse and abstraction and making long-term maintenance easier just do not hold water upon closer inspection.

      Sure, OO may fit the way that *some* people think better, but every head is different.
      • Yeah, you may have a point.

        As far as web backend development goes, I haven't really seen much of an advantage using OO as opposed to just batches of functions. As you said, it can depend on how your mind works. It does keep things a little neater, but is it worth it at the cost of performance?

        Can anyone offer a particular technique they've used in PHP which could not have been done without OO?

        Simon.

  • Dude, don't worry about it. (Score:3, Funny)

    by Anonymous Coward on Tuesday June 03, 2003 @09:23PM (#6111163)
    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 (Score:5, Informative)

    by MikeRepass ( 199982 ) on Tuesday June 03, 2003 @09:33PM (#6111228)
    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

    • Control Flow [cocoondev.org] in Apache Cocoon is one approach can really speed up development and reduce boilerplate code.
    • 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 adv

      • 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.

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

        What about converting "web apps" to web services? seems like this would solve the problem rather nicely, at least foo certain types of applications. You can write the back-end in whatever you want, using standard web languages, but instead of an http front end, you just write up a client, which would be relativley easy, as all it does is gather the info and send it out over http (or SOAP). Since the fornt en

  • Some suggestions (Score:5, Informative)

    by Alpha27 ( 211269 ) on Tuesday June 03, 2003 @09:39PM (#6111251)

    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.

    • object oriented code: definitely helps out.

      I am skeptical of that. Do you have a specific code example? Many things that are put into "objects" could have been put into dictinary arrays instead, for example.
  • Why avoid OOP? PHP supports classes [php.net].

    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 PHP tips (Score:5, Informative)

    by Imperator ( 17614 ) <slashdot2 AT omershenker DOT net> on Tuesday June 03, 2003 @09:54PM (#6111333)

    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 (Score:3, Informative)

      by Blaze74 ( 523522 )
      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
      • I agree. We ran into that with Phorum. Caused us some bad press where files divulged info we did not want divulged.

      • Re:My PHP tips (Score:2, Informative)

        by damien_kane ( 519267 )
        use base.php instead of base.inc

        Not only that, but in case you have some code in base.php that is not called as a function (for example your DB link), put something like this at the top of base.php:

        if (!isset($somekeyvar)) die();

        Then make sure you set $somekeyvar in everypage. This will make sure that code isn't accidentally run when some (non-)malicious user goes looking around.
        Alternatively, include base.php from a path which the webserver does not serve, but still has access to. For example, crea
      • that's what the include path is for
      • I use base.inc.php
        that way the code is run by default (not displayed) but you can also tell apache to handle .inc.php in a different way
        its also just a good way to tell the difference (like using .html and .htmlf)

      • Take what the above poster said, but use base.php instead of base.inc.

        No, use inc and use an .htaccess file to block all requests for files with extension ".inc". You don't want these include files to ever be executed unless it is from inside of a PHP script. As Rasmus Lerdorf calls it, "executing code outside of its context".

    • Every file includes base.inc.
      If you're going to do that, why not automatically prepend the config file using the "auto_prepend_file" setting in php.ini?

    • Template Systems (Score:2, Insightful)

      by JonBob ( 556956 )

      Imperator wrote:

      Use a good template system like Smarty. Just because PHP lets you mix code with HTML doesn't mean it's a good idea.

      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 [phppatterns.com].

      • Re:Template Systems (Score:2, Informative)

        by dismayed ( 76286 )
        As a counter to this...

        If you have to hand off your code to another person who will be doing primarily design, for instance customizing the "look and feel" then using separate templates is really valuable. You will drastically cut down on "bugs" caused by changes in the logic introduced by a designer changing code accidentally.

        Even if PHP is the templating engine, separating the logic is important.

    • On that note, use PHP OO to abstract away the DB.

      That is very difficult unless you stick with a wimply SUBSET of both OO and relational, getting the worse of both worlds. OO and relational are two very different things that don't match up one-to-one for the most part. Further, relational can be a high-level tool if you know how to use it, not a low-level service to just be wrapped over with flat API's.

      If you mean putting wrappers around raw SQL calls, then I fully agree. But, you don't need OOP for tha
    • You might be able to answer something for me. I've shied away from having a "base.inc" or similar other global include file. Doing so might involve having thousands of lines code for each page load. This must take a lot of time for the server to parse, so it would greatly reduce the load capacity of the server. Is this thinking correct or is there something else going on?
      • You're very right that doing this naively will result in just what you describe. PHP will parse all those files to an internal opcode format, then execute that. What you want is for it to cache the opcode so it doesn't have to re-read/parse/compile the .php files until they change on disk. The best way to do this is with the Zend Optimizer [zend.com], which is written by the same people who write the PHP engine. It's free as in beer and comes only as a binary. If you want free as in speech as well, search for "php acc
        • Thanks, will get onto it :) I had heard from somewhere that you had to pay for the 'good version' of Zend, but perhaps it was confusion that begain with merely 'non-GPL'

  • Just Another Hacker's Advice (Score:4, Interesting)

    by eddy the lip ( 20794 ) on Tuesday June 03, 2003 @10:22PM (#6111450)

    (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.

    • 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.

      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 e =>$username,retur n=>"realname");
      db_close();
      return($realname);

      (and then I'd right db_connect, db_get_data, db_close as my own functions s
  • 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?
    • Trends? Hmmmm. That is tough to say. Everyone has their own way of doing things. It is quite common amongst the available PHP applications out there (Phorum, phpBB, PHPNuke, etc.) to have a common.php type of file and/or a config.php file.

      I can't really point you to any URLs as I don't really know any. I can tell you what we do at dealnews.com. That may not be what you want, but it is all I have to offer.

      We have a library or as we call it codelib of about 300 different files. Some are classes, some
    • I'd recommend looking at the PEAR Coding Standards [php.net]. I find that most of the styles of coding that I developed on my own are similar. I changed a few of my habits to conform with PEAR's standard. I don't necessarily ever plan on submitting code to the project, but I like to have a written rule and it's a decent rule, fwiw. Personally, I would like to see these guidelines adopted as industry-standard php coding style, but whatever.

      So, yeah, check that out.
  • 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
    • the real trick is not to use PHP on a per page basis, but as a program.

      I think of my web-apps as applications, not websites, where the browser is the display component. I write one index.php that has a "command line" (an HTTP GET) variable that defines what the "action" is (and any number of other variables necessary)

      the action defines what "page" you're looking at, and then I use a templating language (acutally, I hacked together a very ugly perl html::template port so i can use html::template syntax wh

      • I definitely agree about page-based thinking not scaling. We've got an in-house CMS that has a page based admin feature that started to bother me about half way through development. It includes modules for more complex functionality that you add to each page. I would have tossed it for another metaphor, but quickly realized there was no way we'd be able to get client's heads around something without folders and pages. So I hid as much of what's actually going on as I could behind page metaphors.

        Dying for

  • what I do... (Score:1, Informative)

    by Anonymous Coward
    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

    • Re:what I do... (Score:4, Insightful)

      by brianlmoon ( 322719 ) on Tuesday June 03, 2003 @11:22PM (#6111830) Homepage
      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'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!

  • Here's an elegant way out... Drop PHP (Score:4, Insightful)

    by Randolpho ( 628485 ) on Wednesday June 04, 2003 @12:06AM (#6112078) Homepage Journal
    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 [zope.org], a web application platform based on the Python [python.org] 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 [plone.org]. Zope comes with two powerful templating languages if you don't like straight Python: DTML [zope.org] and Page Templates [zope.org].

    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? :)
    • I wholeheartedly recommend Hurrah [hurrah.com] for Zope-friendly web hosting. The pricing isn't bad, service is great, and their servers seem to be pretty snappy.
    • I'm too late, so someone beat me in zope worshipping ;).

      I should say that I was _never_ in the 10 years I program know for preaching my language/plattform of choice, but if you have gone to zope you'll love it and will never look back (at least surely not if you came from php/perl, and I did them both).

      Just to add two things which I think randolpho above didn't mention (just skimmed the text), these are transaction safeness (never ever write db->commit() ) and it very friendly community.
    • Zope seems like one of those love-or-hate technologies, kind of like Perl. It either rubs you the right way, or the wrong way, with little in between. Some have described it as web development nervana, others describe it as "OO theorists getting carried away with kludgey concepts".

    • Re:Here's an elegant way out... Drop PHP (Score:1)

      by Anonymous Coward
      I've tried it for fun on my OpenBSD box, and it worked pretty nice. Zope was only allowed locally for testing, though.

      For my own part, I just want to put up some pages (at home) without getting hacked during the next 14.13 seconds of running it. I don't know if that applies to Zope, but Zope _do_ use WebDAV, that on MS platform at least, has had some problems...

    • Re:Oh, the pain of Zope (Score:1, Informative)

      by Anonymous Coward
      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've run into some serious challenges starting to use Zope... the documentation is kind of brutal and out of date, with few coherent examples of page templates or external classes. Do you (or anyone else) have non-obvious leads on how to get started building Zope Products or ZClasses beyond the docs on zope.org? Or suggestions offline: zopehelpfromslashdot at remove.this webplumbers.com

      Thanks... I'm really hot to start building stuff but not sure where to start...
      ---
    • Or you could use apache with mod_python - I have never used Zope but i know the python (and mod_python) docs are pretty good... //Adam

  • 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.

  • Designed urls, a cache, templating... (Score:4, Interesting)

    by King of the World ( 212739 ) on Wednesday June 04, 2003 @03:25AM (#6112840) Journal

    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 :(

  • Whenever a new user connects:

    make_secure_connection();
    do_login();
    get_use r _profile();
    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 o
  • 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
  • I use a neat Apache rewriting trick

    RewriteCond %{REQUEST_FILENAME} !-s
    RewriteRule ^(.*\.html$|.*/$) /index.php [T=application/x-httpd-php,L]

    that way when a request for a page that ends in .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.

    the world is an easier place when

    http://www.thebigchoice.com/Graduate_Jobs/IT_an d _M anagement_Systems/York/

    is the URI instead of

    http://www.thebigchoice.com/show_jobs.php?
    • Is it? I prefer the latter because you can put the parameters in any order. The former has the constraint that you have to define the function parameter order as well as their names. What if someone goes http://www.thebigchoice.com/York/Graduate_Jobs/IT_ and_Management_Systems/ ?
      • it's for machines

        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/I T_ and_Management_Systems/

        and

        http://www.thebigchoice.com/Graduate_Jobs/IT_and _M anagement_Systems/York/

        yield (almost) the same page (the url affects the H1 you see)

  • SSTP (Score:2)

    by SiMac ( 409541 )
    You could try SSTP [simonster.com]...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.
  • 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
    • You're not alone.. I love writing big projects in C, but all my PHP work seems very hacky, and when coming back to it after 2 years to make some code changes I can't understand how everything hangs together (despite lots of comments etc). Help!
  • I'm a reasonably experienced Java developer (4 years). We're mostly creating J2EE applications at my work.

    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 ... they all make developing a lot easier.

    Tooling for PHP is another matter. There are editors, there are Eclipse plugins, but nowhere near the level of Java (

  • Core Control (Score:2, Insightful)

    by devvincy ( 455780 )
    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,

  • 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 [midgard-project.org]. 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 [openacs.org] is based on AOL [aolserver.com]

  • Drupal (Score:2, Interesting)

    by swinerd ( 175180 )
    [disclaimer: I'm a Drupal contributor]
    Drupal [drupal.org] 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 ;) cleanliness.
    It's fast and powers sites like Kernel [kerneltrap.org]
  • ...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 TA
    • Just a side note... you can use ZPT's from PHP now also....

      PHPTAL --- ZPT's for PHP [sf.net]

      I have used all the other templating systems, Smarty, phplib, and have used templating systems in perl such as TT2 and find that ZPT's work out very well for keeping the designer happy and me as a programmer happy... Like Smarty PHPTAL is a pre-compiling templating engine, so you end up with quickly executing templates.
    • For an MVC architecture in PHP you should give Phrame [sourceforge.net] a try. Quite cool, but there's a bug in the 2.0 release.
      Easy enough to fix yourself, but I can send you an updated version if you don't like to bother with redo-ing work.. Just reply to this if you're interested.
  • 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!

    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'. TSDFE
    • Just edit your include_path using a .htaccess or by editing your site wide include_path. This way you can include your files using your syntax, require_once "MyApp/file.php"; This type of configuration is common in every other environment, so why not use it in your PHP? :)

      • Hmmm. Well the problem was that I couldn't edit the site wide include_path.

        I wasn't aware that you could put that in a .htaccess file, but I tried it and it worked and I'm rather happy about that :) Just like so:

        php_value include_path /var/www/html/lib

        As I was googling for how to do it just now I found that you can also do this:

        ini_set('include_path','../lib');

        Never knew of that function before, but it works!

        It seems to be time for me to clean up my scripts, again. :)
    • I used to find that annoying too, now I just use this trick at the top of a file

      $base_fs_path = $_SERVER[DOCUMENT_ROOT];
      require_once($base_fs_p a th . "/lib/file.php");
      require_once($base_fs_path . "/lib/other.php");

      If it's the case your app hangs off of the document root such as http://server.com/application then you would edit the $base_fs_path to be like this instead:

      $base_fs_path = $_SERVER[DOCUMENT_ROOT] . "/application";

      Now, this of course much more useful if you use a single "controlling" script fr
  • 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.

    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
  • 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 cl


  • Phrame [sourceforge.net] has already been mentioned.

    Eocene [eocene.net] (Looks very promising)

    php.MVC [phpmvc.net]
  • 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 Smart

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close