Jump to content
Larry Ullman's Book Forums

HartleySan

Members
  • Posts

    3047
  • Joined

  • Last visited

  • Days Won

    243

Posts posted by HartleySan

  1. I would advise against your current approach for reasons that are likely already obvious to you.

    Nowadays, I quite often structure my index.php file as follows for any Ajax-driven pages:

     

    <?php
      
      // Include config file.
      
      // Maybe do some security checks.
      
      // List array of CSS files to include.
      // List array of JS files to include.
      
      // Include header.
      // Include content.
      // Include footer.
     
    I then structure my content include so that it loads all the necessary content on page load, but I can also make Ajax requests to the same script, and depending on the request, I can easily route it to return the HTML I desire.
     
    With that said, depending on the complexity of the page, I very well may have additional scripts for handling Ajax POST requests that insert into or update the DB, so don't feel like you have to or attempt to cram all your functionality into one script.
    If all your files are well organized, having multiple files to handle a page is not a bad thing.
  2. Thanks for the response, Larry.

    I think those are fair statements, but I still feel like the same thing can be easily accomplished with procedural code.

     

    Of course, with procedural code, you have to be more disciplined with namespacing, the hierarchy you set up with helper functions, etc. (because the code won't automatically do it for you like OOP does), but I think that the benefit of procedural code (like you eluded to) is that it is easier to learn, quicker to write, and less bloated.

     

    Really, when it comes down to it, I think that well written code, whether it be OOP or procedural, is going to be quite similar in structure, but with that said, I just find procedural to be less time-consuming and less bloated, which is why I tend to prefer it (at least in PHP and what I use PHP for).

     

    Anyway, thanks a lot for sharing your thoughts.

  3. A 500 error means that there is a syntax error in your PHP that has to be fixed.

    As for echoing the UPDATE query, I mean if you have a query like the following:

    UPDATE users SET name = 'Bob' WHERE id = $user_id;

    Then do the following in your PHP script:

    echo "UPDATE users SET name = 'Bob' WHERE id = $user_id;";

    Doing so will allow you to see the exact query you're executing on the DB, and you can then copy and paste that into phpMyAdmin, and run the query directly on the DB, which will provide more feedback in terms of whether there is an error in the actual SQL, etc.

  4. I just wrote up a long response in reply to your points, Antonio and Larry, but the more I read and re-read my write-up, the more I realized that my thoughts boiled down to one, underlying question:

    Why does OOP make bigger, complex projects easier to maintain?

     

    I ask because I have worked on some massive PHP projects, and I have yet to ever see a case where OOP simplified things.

    On the flip side, in every case I've ever used or seen OOP in PHP, I feel like it's added a lot of bloat to the code, and by direct correlation, dev time.

    Certainly, if you don't use OOP, then you need some logical way of organizing your code, but that to me does not imply that OOP is better.

     

    So, to keep this discussion going and interesting, please tell me specifically how OOP makes bigger/complex projects easier than if procedural code is used.

     

    Thanks.

×
×
  • Create New...