SitePoint Sponsor

User Tag List

Page 2 of 2 FirstFirst 12
Results 26 to 43 of 43
  1. #26
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dan06 View Post
    Is it bad form to have php logic in the html?
    At one point or another, you are basically going to have to include looping or conditional structures in your templates. At this point, it doesn't really matter whether the logic is expressed in PHP or some other templating language. (I find the arguments against specific template engines heavy enough and prefer PHP, but that's beside the point.) What's important is that the logic contained should represent display logic and not business logic of any kind.

  2. #27
    SitePoint Guru
    Join Date
    Sep 2004
    Location
    NY, USA
    Posts
    712
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Stormrider View Post
    Generally, with regards to web apps / programming, scalable refers to the ability to handle an increase in users & traffic. ie, can the application handle multiple servers? multiple db servers? Will it grind to a halt if too many use it?
    to me at least, those are 2 different ideas of scalability, which is why I posed the question. Multiple servers brings in a whole different set of considerations, from the more simple notion of having a single server web app be scalable for a high load of traffic.

    For the latter, I think by far the best defense is caching. Whether your architecture is perfectly optimized or not, you can more or less minimize that factor with proper caching techniques. Put another way, if you are hitting the database on every request, you're just begging for trouble.

    code igniter has built-in caching which is dead simple to implement. .NET also has various built-in caching mechanisms which are also fairly easy to integrate.

    Cache as much as possible.

  3. #28
    SitePoint Guru
    Join Date
    Jun 2006
    Posts
    638
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by TomB View Post
    This is the worst solution yet, imho. You've tightly bound the tempate to the UserDisplay class, so it makes reusing the template for any other case almost impossible
    You misunderstood: the UserDisplay class is PART of the template, all the code in the ___Display classes is meant to be used with those templates only.

    For example: every time you need to print in the user name, you use:
    PHP Code:
    UserDisplay::name($myUser); 
    That way, if you ever decide to add some flag next the the user name (if lets say, they pay you 1$), you only have one pace to change, even if that user name is shown in 500 templates.

    So, the ___Display classes are not used to render HTML in a template, but to render things like user names, dates, x/y/z information. Things that you always want to be the same everywhere.

    Like, when you try to print "welcome [user name]", and no user is logged in / given, you want to print in "welcome guest, login here".


    Quote Originally Posted by TomB View Post
    What if I want to add a class to that register link? It's now abstracted inside the PHP, making it harder to find and more difficult to edit. What if that HTML was significantly more complex?

    You could use another template file, but then you're introducing an extra step (or more) and it takes longer for anyone looking through your code to navigate to the part they want to edit as they have to trace through the code.
    That is exactly this:
    Quote Originally Posted by Vali
    The bad:
    - Your average Joe will not use the 'grep' or 'find' or a good IDE to see what function gets called, so they have to fallow up on the call stack (might take a while)
    Use ecplipse for php or something like that, and everything will be 1 / 2 clicks away.

    If you use VI to make web pages, your in for a treat when you try eclipse or something similar.

  4. #29
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by edzhstar View Post
    I t dependes
    Oh what? Hmmm? Or is that all you have?
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  5. #30
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    989
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by Vali View Post
    You misunderstood: the UserDisplay class is PART of the template, all the code in the ___Display classes is meant to be used with those templates only.

    For example: every time you need to print in the user name, you use:
    PHP Code:
    UserDisplay::name($myUser); 
    I understand now. For site wide things like this it makes sense (though i'd use a separate template, to keep the HTML out of the PHP completley) but what do you do for control structures which are used in one place? E.g. a while looping through a result set, and what about the same logic around different blocks?

    Or, the point I was getting at earlier, when you have the same logic controlling different blocks.


    PHP Code:
    <?php
    if ($user->isLoggedIn()) {
        
    //Show reply button
    }


    if (
    $user->isLoggedIn()) {
        
    //Show new messages
    }

    if (
    $user->isLoggedIn()) {
        
    //Show another users contact info
    }
    ?>
    //Would you do it like this?


    ..html..

    <?php UserDisplay::replyButton($user); ?>
    ..html..
    <?php UserDisplay::newMessages($user); ?>
    ..html..
    <?php UserDisplay::contactInfoForUser($user$user2); ?>
    ..html..
    The logic for those ifs is the same, but the display is different. How do you deal with that? Having a function in the __display class for each case seems like overkill and a maintenance nightmare. It's likely the reply button is only going to be in one place. Then you've moved the template into sliced up HTML in the class itself making it much more difficult to edit and you still cant do a batch update of the logic, if anything doing a mass update of the logic is now more difficult.

  6. #31
    SitePoint Enthusiast
    Join Date
    May 2009
    Posts
    47
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'm going to try to implement the MVC pattern on a simple website I put together - for a model component, I'd like to create a simple database API. Before I take on this endeavor, anyone have any suggestions, recommendations, and/or examples that could help with the database API? Thanks.

  7. #32
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Don't reinvent the wheel, use http://adodb.sourceforge.net/

  8. #33
    SitePoint Zealot Dorsey's Avatar
    Join Date
    Feb 2004
    Location
    NJ
    Posts
    103
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Many replies have focused on methodologies rather than the mechanics of scalability. No matter how you slice it, pretty soon one server doing everything is going to run out of steam. On my current project, our model shows that we can easily handle 100K customers per month on a small hosting plan and we can move up to a dedicated server should the happy day arrive that we exceed that number, but to scale up to millions of customers requires different thinking. My point here is that scalability must be built in and not added on.

    In a previous life, I was part of a huge social networking site that did scale to millions of users spread over several servers with dynamic load balancing and all the other bells and whistles. Without going into the gory details (because people have written books on those details), here are the basics:

    Separate the display, business logic, and data processing into packages/modules that have no pathological connections; i.e., they can reside apart from each other. Working from back to front, a DB like MySQL is already client-server, so that can be split across several servers with the help of a good DBA.

    Develop a business logic library so that processing decisions and direct data access are not embedded in the front-end code. That library can be realized as PHP classes, but enabling that across many servers requires something like an internal web service using SOAP or XML-RPC so that the front-end servers can hand off business logic processing to another server. Lacking COM or CORBA, we created a front-end class library that was nothing more than a shell that communicated with our business logic servers. The front-end developers didn't know the difference and all processing appeared local, but in reality our system used load balancing to send the processing request to the best resource.

    However, now that you have three tiers of code that are completely independent of each other, you can add additional servers at any of those tiers as needed.

  9. #34
    SitePoint Guru
    Join Date
    Sep 2004
    Location
    NY, USA
    Posts
    712
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    And again, don't forget to cache.

    You can speak all day about the merits of n-tiered architecture and best database practices etc. But the first scalability roadblock you will hit is not likely be caused by a flawed architecture - the bottleneck will come from your application struggling more than it has to in order to keep up with demand. Compression and cache directly combat this problem.

    In a high load situation, your application should not be called upon to go through its motions any more than is absolutely necessary. Instead, requests should be answered with a compressed, cached response, ready and waiting with very little resources needed to deliver.

    Obviously you need to refresh occasionally. How often, and what pieces, depends upon your specific needs. But in discussing scalability, you could have the best, most efficient MVC architecture ever assembled with a lightning fast templating routine and perfectly optimized queries... however it will still struggle under a high load if it has to "process" every single request. So use cache!

  10. #35
    SitePoint Guru
    Join Date
    Jun 2006
    Posts
    638
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    TomB, I would do it like this, assuming your talking about a forum thread where logged in users and guests can reply:

    File: thread.php
    PHP Code:
    <?php 
    # Load up the DB connections, auto-loaders and so on.
    require ('conf.php'); 

    # Load the logged in user
    ## this usually goes in some other file, with other checks
    # The 'UserSession' class can extend the User class (in case it needs stuff from there)
    # The 'getLoggedInUser' will return the logged in User, or a new user object (Guest user)
    $P UserSession::getLoggedInUser();

    # Load up my thread id 5
    $thread = new Thread(5);

    // On post save the reply
    if (isset($_POST['btnReply'])) {
      
    $post = new Post();
      
    $post->title $_POST['postTitle'];
      
    $post->message $_POST['postMessage'];
      
    $post->thread 5;
      
    $post->owner $P;

      
    # This sill validate everything, and save it if all good (also if the $P is set)
      
    if ($post->save()) {
        
    # Set the thank you message
        
    logMessage::set('Your post has been saved');

        
    # 302 for refresh
        
    header('location: /posts.php');
        exit;
      }else{
        
    # We found errors, or Guest user
        
    if (!$post->owner->isLoaded()) {
          ...
          
    # Save the $post to the session, redirect the user "register page" or wherever
          
    ...
        }else{
          
    logErrors::set($post->getErrors);
        }
      }
    }

    require(
    'header.php'); 
    ?>
    ... html ...
    Welcome <?php UserRender::name($P); ?>
    ... html ...
    <div class="thread_container">
      ... html ...
      <?php require(render/messages.php); ?>
      <?php require(render/errors.php); ?>
      ... html ...
      <?php
      
    # This part I don't like, since the include uses the $thread and $thread->owner variables
      
    require ('render/thread_owner.php');
      require (
    'render/thread.php');
      
    ?>
      ... html ...
      <?php
      
    # loop all posts and show them
      
    foreach ($thread->posts as $post) {
      
    ?>
        <div class="post_container">
          ... html ...
          <?php
            
    # This part I don't like, since the include uses the $post->owner variable
            
    require ('render/post_owner.php');
          
    ?>
          ... html ...
          <?php
            
    # This part I don't like, since the include uses the $post variable
            
    require ('render/post.php');
          
    ?>
          ... html ...
        </div>
      <?php
      
    }
      
    ?>
    </div>
    ... html ...
    <div class="reply_container">
      <form name="frmReply" action="/thread.php" method="POST">
        <label>Title: <input type="text" name="postTitle" value="default" /></label>
        <label>Message: <textarea name="postMessage">default</textarea></label>
        <?php
        $btnLabel 
    'Post Guest Message';
        
    # This code is only used in this page, so IFs are ok, if not overkill
        
    if ($P->isLoaded()) {
          
    $btnLabel 'Post User Message';
        }
        
    ?>
        <input type="submit" name="btnReply" value="<?php echo $btnLabel?>" />
      </form>
    </div>

    <?php
    require('footer.php'); 
    ?>

    File: render/post_owner.php
    (This file is used every time you render a post, if always the same)
    PHP Code:
    <?php
    if ((!isset($post)) || (!isset($post->owner))) {
      
    # opsy, do something here
    }
    ?>
    <div class="post_owner">
      This post was made by: <?php UserRender::name($post->owner); ?>
      <br />Location: <?php echo $post->owner->location?>
      <?php
      
    # This if is only used here
      
    if ($post->owner->isSpecial == 1) {
        
    # yes, this is bad, but i do it from time to time
        
    echo '<br />Status: <img src="/images/specialPostUser.gif" alt="" title="" width="50" height="50" />';
      }
      
    ?>
    </div>
    Went a bit overboard with that code, but I hope everyone gets the picture.

    At a first glance, some programmers say that there are to many includes around.
    But the ones with some experience soon realize that all the includes are used in more than one page, so they need to be includes.


    The idea is this:
    Good:
    - every time you have a block in 2 places, factor it out in some include. (don't repeat yoruself)
    - kip it simple (KISS)
    - classes are not the only pieces of code you can reuse (within the project)
    - always return what you expect from your classes/functions (if you return NULL, you end up with extra IFs all over)
    - You can do Object caching easily in the includes, and load from DB calls (you only have a few places to do this)
    - unit tests are dead simple to add (you can even tests the includes)
    - you can turn your site to 100% ajax in a day or so (thanks to all the includes)
    - you can use google site optimizer almost as a plug and play module (thanks to all the includes)

    Bad:
    - sometimes, when you render stuff like user names, you can use some 'display'/'render' class to always show the user in the same format / show some other message for Guests.
    --- It's easy to go overboard here and all an entire paragraph of text / 20 IF blocks sometimes. But you will realize that even if this can get messy, it's usually just 2 or 3 places per project (and I'm talking 6000 file projects here, 30mill users, 2bill messages and so on)
    - I don't know of anyway (in php) to include a file, and tell it what variables to use.
    Example: <?php include ('render/post_owner.php', $owner = $thread->owner); ?>
    (that would make the includes more reusable in teams / cut down refactoring time)
    - You have allot of classes, but they are all dead simple.


    ps:
    - I'm talking here about the scalability/management of code (basically so you don't get stuck after 1 year of development with a project you can't update it any more, since your afraid that anything you can change will break something else)
    - For real scalability/management of code, you need to first take a step back, and see the skill level of your team. The idea is, keep everything simple, abstract all the complicated stuff. That way, when someone if "off his game" one day, and commits some "wtf code", chances are that "wtf code" won't be as "wtf" as it could have been. (and I seen some WTF code...)
    - don't forget a good folder structure, I just wrote that code as a quick example.
    - don't forget some version system (CVS, SVN, etc)
    - don't forget to plan for change (it's a website, you start with a shopping cart and end up with a porn site... that's how it goes)


    Hope this helps someone, took a while to write.

  11. #36
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    989
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    Wow.. spaghetti code anyone?

    Without wanting to sound harsh, thats the kind of page structure I'd expect to see ten years ago with a .php3 extension (excluding the few OO Parts). Look up MVC or at least design patterns.

    This kind of code is far from maintainable. Having worked on (and having to rewrite it..) code like this, reusability is almost nil, finding where something happens becomes very difficult because you have so many files. Nothing is grouped into related functionality introducing a lot of guesswork. Finally, you're using the global namespace which means potential name clashes. If one of your includes uses a variable with something your using, you'll have a bug that's hard to track down.

    The biggest problem is you end up with horrible nested control structures which become a burden when it comes to changing them.

    Finally, you have no OO polymorphism so any kind of one off change needs to be an if statement in the code itself:


    Where I used to work I saw code like this all the time:

    PHP Code:
    if ($clientId == 123 || $clientId == 235 || $clientId 321) {
        echo 
    'foo';
    }
    elseif (
    $clientId == 222) {
        echo 
    'bar';
    }
    else {
        echo 
    'foobar';

    Which is just horrible, and it's what your code is driving towards. ($user->isSpecial?) Might look ok there, but what if you have 300 user types who all see something different in that spot. You'll end up with a long if.

    Rather than $clientView->output(); with a Factory to create $clientView based on the client, which is now also reusable.


    My code to do similar to what you posted.

    The controller:

    PHP Code:
    class ThreadPage extends Module {
        public function 
    show() {
            
    //Want different user types to see something different? Use something like $view = ThreadFactory::getView($user); but it's beyond the scope of this example
            
    $view = new Thread_View;
            
    $this->write($view->show());
        }
        
        public function 
    addReply() {
            if (
    $this->auth->checkSession()) {
                
    //rebuild the form, this will get automatically populated from POST (or get if that's $form->method)
                
    $form = new ReplyForm;
                if (
    $form->isValid()) {
                    
    $reply = new Reply;
                    
    $reply->text $form->getValue('text');
                    
    $reply->date = new DateTime2//Custom extended version of DateTime
                    /*
                     * For larger data structures, you can use forms like:
                     *  (form->build() {
                     *     $this->add(new FormTextArea('post[text]'));
                     *     $this->add(new FormTextArea('post[title]'));
                     * 
                     * 
                     * Then create the post object:
                     * $reply = form->createObject('Reply', 'post');
                     * which will create and instance of Reply with the values from $_POST['post']
                     */
                    
    $reply->save();
                    
    $this->show();
                }
                
    //would really be done with a template, but this is here to keep it simple
                
    else throw new Exception('The form returned the following errors: ' implode($form->getErrors(), '<br />'));
            }
            else throw new 
    Exception('You must be logged in to add replies.');
        }    


    The Thread_View class

    PHP Code:
    class Thread_View {
        public function 
    show() {
            
    Template::loadTemplateFile($this->dir 'templates/thread.tpl');    
            
    $template = new Template('ViewThread');
            
    $topic = new Topic($this->request->id);
            
    //This is a generic search replace hook, it can be easily extended to contain any required logic
            
    $template->addHook(new ObjectSetHook('reply'$topic->getReplies()));
            
            
    //This just matches {topic property="title"} for example to substitute for $topic->title;
            
    $template->addHook(new ObjectHook('topic'$topic));
            
            
    //build the form
            
    $form = new ReplyForm('replyform');
            
    //Assign the form to the template
            
    $template->addHook(new FormHook($form));
            
            
    //Hide the reply button if they're not logged in
            
    $template->hideSection('addreply', !$this->auth->checkSession());
            
            return 
    $template->output();
        }


    For completeness, the ReplyForm class:

    PHP Code:
    class ReplyForm extends Form {
        public function 
    build() {
            
    $text = new FormTextArea('text');
                    
            
    //These are all optional
            
    $text->validation '^.+$'//not needed to use regex but here for completness
            
    $text->label 'Description';
            
    $text->validationMessage 'Description';
            
            
    $this->add($text);
        }

    And finally, the template file:


    Code:
    <templatefile>
    	<!--  This section is just here for maintainability, it's not looked at by the template class-->
    	<description>Displays a single thread</description>
    	<usedBy>thread.page.php</usedBy>
    	
    	<!--  Now any templates which are used on this page, there can be more than one -->
    	<template name="ViewThread">
    		<h1>{topic property="title"}</h1>
    		
    		<reply>
    		<div>
    			<p>Posted by: {item property="user::name"}</p> 
    			<p>On: {item property="date"}</p>
    			<p>Message: {item property="text"}</p>
    		</div>
    		</reply>
    		
    		<addreply>
    			<form action="thread/{topic property='id'}/reply">
    				{replyform label="text"} {replyform field="text"}
    				{replyform field="submit"}
    			</form>
    		</addreply>
    	</template>
    </templatefile>

    Everything here is separated into classes, meaning everything can be extended and substituted with ease, it's all also fully reusable.

    I won't go into how the Template class works, because it's not really relevant, the point here is the structure of the code.


    To use it I do

    PHP Code:
    $module = new ThreadPage;
    $module->show();
    echo 
    $module->getOutput(); 
    How this is accesed is an entirely different issue (google front controller)


    Well I didn't intend to write that much.

  12. #37
    SitePoint Guru
    Join Date
    Jun 2006
    Posts
    638
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Difference is, my code can handle 500 requests per second, and yours 50...

    Ok, not that exact code; but the exact same piece of code, one done with smarty because it was 'better', and one done in plain php, because it would save us 30 servers...

    We actually got around 150 requests per second with smart, after fine tuning, and caching and all, and 2000 requests per second for our plain php. (This was for a "social networking", heavy use of DB and caching for inter-user interaction, etc.)

    If you look again at my code, you will notice that I posted no business logic there, just display logic.

    I have 1 to 4 classes for each object, and each object represents a record in my DB (not exactly, but kind off).

    - User: This can be used as a DTO, in or outside the website, but also contains the business logic linked to the user.
    - UserRender: This can only be used in the template, contains some display logic (like add a * next to users names that payed). The functions from this class usually take in a 'User' object.
    - UserSession: This can be used in the website only, since it uses the session. It also extends the 'User' class.
    - UserOptimisation: This class can be used to optimize pages. Since my objects are eventually cached, I can use this class to load a batch of them from the DB, instead of loading them 1 by 1. This needs some examples for clarification...

    Example:
    PHP Code:
    // SELECT * FROM thread WHERE thread_id = 5;
    $thread = new Thread(5);
    // SELECT * FROM posts WHERE thread_id = 5;
    foreach ($thread->post as $post) {
      
    // SELECT * FROM users WHERE user_id = [post->owner_id] << opsy, many queries
      
    echo $post->owner->name "\n";

    You get 3 to N queries here (assuming nothing is in memcache).


    Optimized example:
    PHP Code:
    // SELECT * FROM thread WHERE thread_id = 5;
    $thread = new Thread(5);
    // SELECT * FROM posts WHERE thread_id = 5;
    // SELECT * FROM users WHERE user_id IN ([posts->owner_ids]);
    ThreadOptimisation::precacheUsers($thread->posts);

    foreach (
    $thread->posts as $post) {
      
    // data already cached
      
    echo $post->owner->name "\n";

    You get 3 queries here (assuming nothing is in memcache).


    So, when it comes to "spaghetti code", the only "bad" thing with it is that the includes, use a global variable. (and like I said... not sure how to change that, without using smarty or "load html in a variable, and regex replace some tags...").

    The rest, everything is clear cut in it's place.

    All classes can be reused, in web pages or not, include blocks can be reused in your entire website, but as you said, you have to be careful with their variables...

    My solution so far is to place all variables in an array, keyed with the block name. (but it's not perfect).

    Does this clarify a few things?

  13. #38
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    989
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    The code you posted above has no relevance to the display logic in your previous post. That's a question of how the model interacts with the database and is the same in any system.

    Finally, OO code is (marginally...) slower, agreed. But servers are far less expensive than development time. Optimisation should be done, of course. But not at the expense of maintainability or clean code.

    Global variables may be the only issue that will cause you bugs. But the way the code is structured, reusability is incredibly limited, you can't extend a class.

    For example, in my system I can change the view for admin users to look like this:

    PHP Code:
    class Thread_View_Admin extends Thread_View {
        public function 
    show() {
            
    $thread parent::show();
            
    $template = new Template('AdminThreadOptions');
            return 
    $thread $template->output();
        }

    Which could add Delete, Lock, etc for admins.


    My controller would have something like

    PHP Code:
    $view ThreadFactory::getView($this->auth->user); 
    The factory would be something like:

    PHP Code:
    class ThreadFactory {
        public function 
    getView(User $user) {
            return  (
    $user instanceof AdminUser) ? new Thread_View_Admin : new Thread_view;
        }


    Which makes for easy logic substitution and high reusability. On a procedural system, the only way of doing this is moving the logic into an illogical place.


    At runtime I can substitute, any one (or more) of:

    -The view
    -The template used by the view
    -The logic running the template

    With your system you can only substitute the template.


    With procedural style code you cant even call one page from another and are forced to rely on redirects (which will be far worse for the server than OO code because it has to do a whole extra request and probably fetch some of the same data it just used). By which i mean on my addReply function i can call $this->show().

    This has turned into an OO vs Procedural debate and I think we both know which one has been proven to win time and time again

  14. #39
    SitePoint Wizard Ren's Avatar
    Join Date
    Aug 2003
    Location
    UK
    Posts
    1,060
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by cringer View Post
    Cache as much as possible.
    The key to this is understanding HTTP, and particularly its Vary header.

    Once that's understood, fragment caching means you can cache almost anything, for everyone, a subset of people, or even on an individual level.

  15. #40
    SitePoint Enthusiast
    Join Date
    May 2009
    Posts
    47
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac View Post
    Don't reinvent the wheel, use http://adodb.sourceforge.net/
    What about PDO? Is that a 'good' option for database abstraction or should it be avoided?

  16. #41
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    IMO PDO is OK, but ADOdb has a larger (and better-designed, in some aspect) feature set. And if you can install your own extensions on the server, ADOdb is blindingly fast.

  17. #42
    From space with love silver trophy
    SpacePhoenix's Avatar
    Join Date
    May 2007
    Location
    Poole, UK
    Posts
    5,032
    Mentioned
    103 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac View Post
    IMO PDO is OK, but ADOdb has a larger (and better-designed, in some aspect) feature set. And if you can install your own extensions on the server, ADOdb is blindingly fast.
    I've not heard of ADOdb before, is it the successor to PDO?
    Community Team Advisor
    Forum Guidelines: Posting FAQ Signatures FAQ Self Promotion FAQ
    Help the Mods: What's Fluff? Report Fluff/Spam to a Moderator

  18. #43
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Actually you might say it's a predecessor. It's much older, it's been around for years now.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •