Wondering about what is "good form" for PHP code



  • One of my backburner projects that I've been working occasionally on is a PHP-based CMS system - but after DLing a bunch of PHP projects off teh intarwebs, I've noticed that a lot of people seem to use a class-based system for giving information to the user, while I simply use a bunch of require()'s to build a page. Is there anything inheritly bad about doing this? 

    I feel it improves the readability of the code (or at least makes it more logical, perhaps), and it seems to at least work for me - but if everyone else uses a class/function based method, I dunno if I'm doing it "right', per se.

    I've temporarily uploaded a zipped source of my index.php file to an equally temporary host, at http://www.zendurl.com/dagon/index.zip , if anyone wants to see what I'm talking about. The actual CMS itself is hosted on the same site, though it's only half completed so most of the vital features for a CMS don't exist yet.



  • (Warning: smartass reply may follow)

    Good form in PHP is to not use PHP. Having worked with a number of PHP based projects this is not just an uniformed opinion, but probably the best advice you can get.

    With version 5 PHP seems to be trying to add more OO features on top of the mess of functions in the flat name space that has been composting for years. Depending on which version you're targeting, you can live in require-land (seen it lots of times) or try the new class system (it doesn't make things a lot prettier.) I couldn't call either of them good form, however.

    PHP simply is a language for single developers to rewrite a (forum | CMS | blog) system that someone else has written before them. The language is in a constant state of rewriting systems that already exist. You have to wonder why that is, and why there never is a system that's happily accepted. I suppose it's just the fate of the language:

    1) It's mostly used by new/inexperienced programmers who need to customize a system written by

    2) another mostly new/inexperiences programmer who .. see #1

    So we're left with a good hundred PHP forum systems (I'm pretty sure I've used most of them and haven't found a good open source one) maybe half as many CMS and blog backends, and uncountable number of other insecure scripts.

     
    Please ask yourself, "must you use PHP?" If you really see no other way, then make your life easier by reusing existing code -- that's good form. Rewriting from scratch is.. well, I know everybody does it so chances are that I can't stop you, but in that case it really doesn't matter how you do it ;-)
     



  • Split up your layout/design from your functional code. Makes your life easier as you don't have to look for your layout code in your functional code, and makes the site designer (html wizard) life easier as he doesn't have to look at your code.

    Take a look at smarty: http://smarty.php.net/ 



  • If you can bear some PHP code in your HTML files (like when you both code and design the page), then use PHP as the templating engine:

    1. Put all functional (as in "doing all the work") code of a page in one PHP file and save any results of the processing to non-WTF-named variables.
    2. After everything is done, require() an HTML file with inserts of PHP code (you can use short tags to be concise) to output the processed information. You can also use loops to output sets of data which vary in length, i.e. like this:
    <? for($i=0; $i<count($results); $i++) { ?>
    <tr>
    <td>Result <?= $i ?>:</td>
    <td><?= $results[$i] ?></td>
    </tr>
    <? } ?> 

    This way, you can have both a clean PHP code and (relatively) clean HTML code. I like this technique, because it doesn't require you to install and learn to use a templating engine (I had written my own one time, not knowing that such things existed). Anyway, templating engines tend to suffer from The Inner-Platform Effect.



  • Isn't embedding PHP in HTML bad practise?

     

    I do this:

    $html;

    $html .= "<p>Hello World!</p>";

    echo $html;



  • @Ice^^Heat said:

    Isn't embedding PHP in HTML bad practise?

     

    I do this:

    $html;

    $html .= "<p>Hello World!</p>";

    echo $html;

    Actually, that's worse. You *never* want to embed HTML in your code. Embedding minimal code with your HTML is better practice.

    The advice given was not to do your *processing* within the HTML, but to use PHP as a *templating* engine. You only insert end-result variables, and loop if you have to.

    More modern web-aps use XML namespaces to accomplish the same effect. For example, an ASP.NET page might look like this:

    <%@ Page Language="C#" AutoEventWireup="true"  CodeFile="Default.aspx.cs" Inherits="_Default" %>
    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
    <html xmlns="http://www.w3.org/1999/xhtml" >
    <head runat="server">
        <title>Hello World Page</title>
    </head>
    <body>
      <asp:Literal ID="howdy" runat="server"></asp:Literal>
    </body>
    </html>

    and the codebehind might have

    public partial class _Default : System.Web.UI.Page
    {
        protected void Page_Load(object sender, EventArgs e)
        {
            howdy.Text = "Hello World!";
        }
    }

     

    In PHP, you would accomplish the same thing in a less OO way like this:

    <?php require("PageCodeBehind.php");>
    <html>
     <head>
      <title>Hello World Page</title>
     </head>
     <body>
       <?= $howdy; ?>
     </body>
    </html>

    And PageCodeBehind.php would contain:

    <?php
      $howdy = "Hello World!";
    ?>



  • @Whiskey Tango Foxtrot? Over. said:

    In PHP, you would accomplish the same thing in a less OO way like this:

    This is not OO, it's just an (unnecessarily complicated) extra layer of abstraction.



  • @asuffield said:

    @Whiskey Tango Foxtrot? Over. said:

    In PHP, you would accomplish the same thing in a less OO way like this:

    This is not OO, it's just an (unnecessarily complicated) extra layer of abstraction.

    Er.... I'm having trouble parsing the subject in your sentence. Do you mean that my PHP example is not OO? I never claimed it was.

    Or do you mean that the ASP.NET example is not actually OO even though it claims to be?



  • @asuffield said:

    This is not OO, it's just an (unnecessarily complicated) extra layer of abstraction.

    That's not "unnecessarily complicated". That's virtually "how you do it properly".

    My site has one main php page with almost all its HTML. It's basically the template. I require my site's specific lib, plus a generic one, and inside the BODY is one main function that calls submethods of sections for which to execute queries and write HTML. My site's structure is reflected in a (nested) case switch. I'm still not quite sure if that's good form in general, but it looks pretty to see a code tree that === your site. :)

    The main point is to shove and shuffle reusable bits into single places, to facilitate editing code.

    In addition, I switch in and out of server-side delimiters <? and <% when I have about 3+ lines of HTML. Syntax colouring for the win. HTML in strings for the lose.



  • @Whiskey Tango Foxtrot? Over. said:

    @asuffield said:
    @Whiskey Tango Foxtrot? Over. said:

    In PHP, you would accomplish the same thing in a less OO way like this:

    This is not OO, it's just an (unnecessarily complicated) extra layer of abstraction.

    Er.... I'm having trouble parsing the subject in your sentence. Do you mean that my PHP example is not OO? I never claimed it was.

    Or do you mean that the ASP.NET example is not actually OO even though it claims to be?

    The latter. OO-ness is not about introducing extra layers of abstraction. Sadly, a lot of the stuff in ASP.NET was done by people who come from the "OO means anything with the word 'Object' in it somewhere" school of thought.

    OO is a *design* feature. Nothing in the design of this ASP.NET feature is OO. There are language features here which are intended to help you implement an OO design. Those language features themselves are not "OO", in much the same way that the shirt you are wearing is not you - the presence of your shirt does not automatically mean that you are here also (and in fact, most of the time you are not in the same place as that particular shirt - hey, this analogy is working out better than I had planned).



  • @dhromed said:

    @asuffield said:

    This is not OO, it's just an (unnecessarily complicated) extra layer of abstraction.

    That's not "unnecessarily complicated". That's virtually "how you do it properly".

    It uses a great deal of words and punctuation where far less would have sufficed. That's "unnecessarily complicated" in my book. One of my pet peeves about .NET stuff is that much of it was designed by people who clearly love to talk interminably and at great length, and assume that everybody else wants to emulate them.



  • @asuffield said:

    The latter. OO-ness is not about introducing extra layers of abstraction. Sadly, a lot of the stuff in ASP.NET was done by people who come from the "OO means anything with the word 'Object' in it somewhere" school of thought.

    OO is a *design* feature. Nothing in the design of this ASP.NET feature is OO. There are language features here which are intended to help you implement an OO design. Those language features themselves are not "OO", in much the same way that the shirt you are wearing is not you - the presence of your shirt does not automatically mean that you are here also (and in fact, most of the time you are not in the same place as that particular shirt - hey, this analogy is working out better than I had planned).

    I suppose I can accept the argument that how you write your code defines whether or not it is object-oriented, not how the code executes. If that's what you mean. I cannot shake the feeling that your complaints stem from the fact that you're one of those guys who writes "M$", and that makes it hard to figure out your exact objection.

    Still, it's irellevant -- but that's probably my fault for not being more precise. By "less OO" I meant that in the PHP example the code-behind is a straight execution -- it's not even *structured*, it's just a single assignment statment -- whereas in the ASP.NET code-behind a class is defined with a method that acts as an event handler. The PHP example was, therefore, less OO than the ASP.NET example.

    Regarding ASP.NET and object orientation: ASP.NET is very much object-oriented. The means by which it is most commonly attained -- the designer/markup + code-behind -- may not be OO. That's true. It is, however, compiled into fully OO code. In fact, the means by which an ASP.NET page is created -- again, the markup + code-behind -- is entirely extraneous, even unnecessary. You can write a page entirely in C# or VB, without ever entering the designer and creating the markup. It's quite possible. You don't even have to write a single character of *HTML* in your code and you can still build a fully functional, even *gasp* standards-compliant web page. You just build a DOM.

    That's not to say that the DOM is OO, because it's not. It's a composition hierarchy; it's structured, not OO. Perhaps that is your objection. If so, you need to look closer: the classes that output HTML and organize themselves into a DOM hierarchy are very much object-oriented, featuring such object-oriented hits as inheritance, encapsulation, and polymorphism.

    I'm no huge fan of ASP.NET, so it almost hurts to defend it like this, but ASP.NET is definitely fully object oriented. That's one of its strengths. Maybe the designer XML isn't OO, but all you have to do is pop the hood to see all the OO goodness underneath. Too bad it's sullied by billions of stupidly used postbacks.

    /me wanders off muttering about the evil that is the postback.



  • @Whiskey Tango Foxtrot? Over. said:

    @asuffield said:
    The latter. OO-ness is not about introducing extra layers of abstraction. Sadly, a lot of the stuff in ASP.NET was done by people who come from the "OO means anything with the word 'Object' in it somewhere" school of thought.

    OO is a *design* feature. Nothing in the design of this ASP.NET feature is OO. There are language features here which are intended to help you implement an OO design. Those language features themselves are not "OO", in much the same way that the shirt you are wearing is not you - the presence of your shirt does not automatically mean that you are here also (and in fact, most of the time you are not in the same place as that particular shirt - hey, this analogy is working out better than I had planned).

    I suppose I can accept the argument that how you write your code defines whether or not it is object-oriented, not how the code executes. If that's what you mean.

    That's part of it. 

     

    Regarding ASP.NET and object orientation: ASP.NET is very much object-oriented. The means by which it is most commonly attained -- the designer/markup + code-behind -- may not be OO. That's true. It is, however, compiled into fully OO code.

    That's the mistake I'm pointing out. Just because ASP.NET is full of object-sounding syntax does not mean that any code written with it will necessarily be OO. It is entirely possible to write non-OO code in object-obsessed languages (as Java programmers have proven many, many times). It is even possible to write non-OO code when the language designer has deliberately set out to try and stop you (like in Eiffel). A sufficiently ingenious programmer can write FORTRAN code in any language - and often does.

    By "less OO" I meant that in the PHP example the code-behind is a straight execution -- it's not even *structured*, it's just a single assignment statment -- whereas in the ASP.NET code-behind a class is defined with a method that acts as an event handler. The PHP example was, therefore, less OO than the ASP.NET example.

    So my point, therefore, is that neither of the two examples are making use of any OO features, so they both have exactly the same amount of OO-ness in them (none). The ASP.NET example has some object-sounding noise in it, but that's just because the system forces you to - in *this code*, it's an overhead, not an advantage. The only operational part, in both cases, is an assignment statement. The 'design' of both was simply "assign one value", and there's nothing OO about a simple assignment (nor should there be).



  • Hmm...

    It seems you're picking at nits here, but I'll humor you. How about you continue by defining what you mean by object oriented.

    Also, since you wish to pick at nits, I have a nit to pick: there is no assignment statement in the ASP.NET example, although it looks like one. It's actually a method call:

    howdy.set_Text("Hello World!");

    Yay, syntactic sugar.



  • @Whiskey Tango Foxtrot? Over. said:

    How about you continue by defining what you mean by object oriented.

    I'm not really interested enough to take this much further, but briefly:

    If you are collecting related data and methods into objects for the purpose of encapsulation, or for the purpose of code reuse through inheritance (and related features), then your design has object-oriented elements to it. If you're not doing this for at least one of those two reasons, it probably doesn't.

    It's kind of a rough definition, but in practice it works quite well, and it's hard to do much better without writing an entire essay on the subject. There's a whole bunch of corner cases (randomly collecting unrelated methods into arbitrary classes is not object-orientation, no matter how complex the inheritance tree), but they're mostly WTFs anyway.



  • @asuffield said:

    If you are collecting related data and methods into objects for the purpose of encapsulation, or for the purpose of code reuse through inheritance (and related features), then your design has object-oriented elements to it. If you're not doing this for at least one of those two reasons, it probably doesn't.

    And my ASP.NET example, deriving as it does from System.Web.UI.Page which provides a bunch of web-oriented features, does not fit this defintion how?



  • @Whiskey Tango Foxtrot? Over. said:

    @asuffield said:

    If you are collecting related data and methods into objects for the purpose of encapsulation, or for the purpose of code reuse through inheritance (and related features), then your design has object-oriented elements to it. If you're not doing this for at least one of those two reasons, it probably doesn't.

    And my ASP.NET example, deriving as it does from System.Web.UI.Page which provides a bunch of web-oriented features, does not fit this defintion how?

    It doesn't use any of them. It is a single assignment. A single assignment does not involve encapsulation or code reuse.


Log in to reply