SitePoint Sponsor

User Tag List

Page 3 of 4 FirstFirst 1234 LastLast
Results 51 to 75 of 87
  1. #51
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Andrewaclt
    Does anybody besides selatos have a take on my previous post as how to handle a page class (and regards to Harry's article on sitepoint?)?
    Maybe you could start a new topic for that?

    I'm not sure where we've got to in this one. Hopefully we've established that OOP isn't going to slow down your app - although bad code might (even then you'll probably have to try quite hard).

    I was kind of interested in the comments about php4 OOP being flawed?

  2. #52
    SitePoint Zealot Selatos's Avatar
    Join Date
    Aug 2002
    Location
    USA
    Posts
    144
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    well, the only things that I don't like about php4 OOP include the lack of overloading functions, and then no support for full serialization. I don't know if either of these things have been added in PHP5.

  3. #53
    ********* wombat firepages's Avatar
    Join Date
    Jul 2000
    Location
    Perth Australia
    Posts
    1,717
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hopefully we've established that OOP isn't going to slow down your app
    did we ? I saw it as quite possibly the opposite , and here we are now we are talking recursive template parsing and OO producing <tt> tags at runtime ..

    Of course the advantage of reusability and refactoring of OO is massive , but the load is a real issue for an interpreted language.

    I use OO , not to the extent or with any way near the skill of most here but I use it none-the-less , what I do not (mostly) use it for is the sharp-end , e.g the bit that your webserver will (hopefully) be parsing many, many times a second .

    FUD forum kind of made my mind up for me with pre-'compilation' of templating ,functions for FUD but could just as easily be OO , compliation to HTML that is , or just to simpler static PHP routines , its along the lines of what I have been playing with for a while but it was nice to see someone who knew what they were doing, doing it

    My non-OO background means that I am only recently discovering and beginning to understand some of the 'patterns' that are so beloved here , indeed I am already using some of them I just did not realise.

    So IMO even accepting ALL of OO's advantages one still has to look at the bigger picture , an interpreted language has certain issues & they need to be addressed.

    In some implementations of course it does not matter , my own code/framework generators are slow and heavy and full of hacks and some simply awful code , BUT , the code they generate is fast & compact & stands half a chance on a busy server , I don't care how slow the generators are but I do care about how fast the output/result is.

  4. #54
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks

    So what you do is make a template out of templates?
    Pretty much sums it all up

    and then create a Fragment class.
    Much as what I've done, basically it just fetches the required template file, with a class method to replace a given tag with data, and when required, return the template file it's self, back to the View

    Now I'm reading Advanced PHP Programming so I can try to work out the best approach to cache the templates ?

    But I'm still thinking just what should I cache ?

    * the semi complete template which is built up via the template fragments that are non dynamic, or
    * cache each template fragment as it is, dynamic or not, which are fetched (if exists) instead of generating the template ?

    With the approach I have, it offers a lot of flexibility, though there can be a lot of file includes which I'm thinking may be unwarranted overhead, so caching will help considerably (I hope ).

    But, yes, post your new script when you've finished and ran some tests with it, and I'll see what I think of it tomorrow

    Would be interesting to see what you come up with

  5. #55
    SitePoint Zealot Selatos's Avatar
    Join Date
    Aug 2002
    Location
    USA
    Posts
    144
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The way i had planned on implementing caching was taking a serialized version of the object, and saving it in the database. Then, when the script is run, I just check if the cache is less than, say 5 minutes old, and if so, just unserialize the object and call the show() method(yes i know this can have "unpredictable" results, but i'm praying that full serialization will be one day available. That and when i did it in a PHP-GTK app, it has worked everytime perfectly as expected.)

    Yeah I'll be sure to work on it.

  6. #56
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hopefully we've established that OOP isn't going to slow down your app
    OO Programming offers a lot of advantages which I'm not going to go into as you should by now know of them

    But in my view, using OO does offer very good performs in regards to server performance <> page hits ratio

    What overheads there are, the advantages of using OO far outways the disadvantages, if there are in fact, any ?

    All this talk about OO being slow is basically all bulls*** as at the end of the day, you'll not do a better job of an OO driven application with plain procedural programming, and I'll defy anyone to say differently

    So just sit back, relax and enjoy the finer things OO offers

  7. #57
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    PHPversion5 has I think, better serialisation which I'm looking forwards to

    I still need to run some benchmarks on my scripts, nothing too intensive though, just seeing how long it'd take to render an average page

    For example, comparing building a single template fragment against a (test) template fragment to be inserted into the template shell.

    If there is a big difference, (like, is it going to be worthwhile?) then I'll opt for the first option.

  8. #58
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by Andrewaclt
    As a sidenote - besides the GoF is there any suggested reading (webbased or not) about basic oop design?
    In the more advanced category (which I think is what you want)...

    Roles, Responsibilities and Collaborations - Rebecca Wirfs-Brock
    This can be a bit stodgy, but everything she says always turns out right once you try it.

    Agile Software Development - Robert Martin
    Lot's of stuff here, some of it more controversial

    Domain Driven Design - Eric Evans
    How to build high level object models from requirements and keep them on track.

    Object Oriented Software Construction - Bertrand Meyer
    Low level stuff with plenty of definitions. More academic in style.

    Also check out the C2 wiki and The Pragmattic Programmer by Hunt and Thomas.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  9. #59
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    @firepages: Yours is a good post. My comments aren't aimed at you, it's just that you have nice juicy quotable bits...

    Quote Originally Posted by firepages
    did we ? I saw it as quite possibly the opposite
    I don't think we have established anything. We won't without more infomation.

    Quote Originally Posted by firepages
    Of course the advantage of reusability and refactoring of OO is massive , but the load is a real issue for an interpreted language.
    The load from an interpreted language will be high if not much else is happening within a script. Parsing is an example where a lot of calculation happens and where an interpreted language hurts. It doesn't matter whether it is OO or not. Look at a "functional" language like XSLT - hardly a speed demon. For that matter try writing code in Lisp or Prolog or Awk.

    Quote Originally Posted by firepages
    BUT , the code they generate is fast & compact & stands half a chance on a busy server , I don't care how slow the generators are but I do care about how fast the output/result is.
    Yes .

    Code generation is a good way of optimising sections of code, effectively unrolling some of the logic. This is especially effective in PHP when combined with a bytecode cache. We use it in a few places.

    The tricky bit is getting the order right. Code generation is complex, putting another layer and language between you and the final output. It makes maintanence that bit harder. You really need the code generated section tucked away behind an effective interface. Once isolated it can perform it's magic without damaging the rest of the code base.

    In order to get this level of isolation you will have to start from a well factored design. This is the nub. There are two times to think about optisations (such as code generation). Once at the beginning to decide if the whole application approach is feasable (back of envelope stuff) and again towards the end (the real engineering work). The bit in the middle should just be designed well, without regard to performance. Once it's well factored, then optimise.

    How much did your code generation buy you? A factor of two at least, right? Say OO slows the code down by a third (unlikely in my experience) assuming you ignore the positive performance impact it has on the client code. If OO gives you the option to employ a generation solution without cutting across the codebase, you are still winning by a massive margin when you switch to OO. This kind of improvement is typical.

    That's why, once you start optimising for real, OO codebases usually win in the end for performance. They enable more radical solutions.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  10. #60
    SitePoint Evangelist
    Join Date
    May 2004
    Location
    New Jersey, USA
    Posts
    567
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff
    This shifts the focus from php OOP to programmers' skills. Can we agree that you won't get punished for using OOP per se - but you will get punished for writing bad code of either flavour?
    No. I think you've missed my point, here: The 'trap' behing PHP4+OO is that you have to learn 'special' skills to do OOP in PHP4. Not just 'learn how to do OO', but 'Learn how to do OO in such a way that your internal OO-bogometer does not explode, and at the same time PHP4 performance isn't terrible.'

    That's a tall order in its own right. The general lameness of PHP4's OO implementation doesn't help.

    FWIW, I'm exploring PHP5 right now. It's like running out of the men's locker room onto the floor of a stadium -- the air is fresh, the sun is shining, the crowd is cheering, and the cheerleaders are naked. (Well, they are in my mind...)

    =Austin

    (I have no performance opinion on PHP5 yet.)

  11. #61
    SitePoint Evangelist
    Join Date
    May 2004
    Location
    New Jersey, USA
    Posts
    567
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Andrewaclt
    A common theme throughout this thread is seperating your display code from your logic code..but what about Harry's oop page class...(http://www.sitepoint.com/article/object-oriented-php/4 about half way down) Doesn't it violate this in addHeader/addFooter? Is there a better way to do this?
    The one where he says this, about two sentences above the code?

    Quote Originally Posted by HarryF
    This isnít intended to be an example of great design; itís simply a primer in PHP syntax.
    Yeah, it violates a lot of things. But it's a primer in PHP syntax. Give a writer a break, eh?

    =Austin

  12. #62
    SitePoint Evangelist
    Join Date
    May 2004
    Location
    New Jersey, USA
    Posts
    567
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff
    There are no disadvantages ...
    In the United States right now there are about 40 million Demicans running around saying 'John Kerry is going to be the next president!'. There are likewise about 40 million Republocrats running around saying 'George Bush is going to be the next president!'

    Sometime in November (God willing!) there will be 40 million disappointed people. Saying a thing over and over doesn't make it true.

    (I will grant that OOP is, to paraphrase WLSC, the best form of the worst kind of development.)

    =Austin

  13. #63
    SitePoint Evangelist
    Join Date
    May 2004
    Location
    New Jersey, USA
    Posts
    567
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    In the more advanced category (which I think is what you want)...
    Let's not forget the basics:

    Object-Oriented Design, Grady Booch

    A disproportionate amount of what he wrote is still relevant. Keep in mind that the original version (it has been updated a few times) was one of the founding works of the OO space.

    If you can find one of the versions where he compares Ada against Common Lisp (CLOS), take a look at the comparison appendices -- it's right in line with this thread, discussing dispatch costs versus dynamism.

    =Austin

  14. #64
    SitePoint Addict
    Join Date
    May 2003
    Location
    Calgary, Alberta, Canada
    Posts
    275
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi,

    My take on this is that a script written in a procedural style will execute faster than a script written with an OO style 99% of the time. However a programmer should be able to write many more scripts using OO than writing Procedural in the same amount of time.

    An example:
    This is how I would write a script to display a list of articles using a procedural style.
    PHP Code:
    <?php
    if (!$conn = @mysql_connect('localhost''''')) {
        
    trigger_error('Invalid database connection settings');
    } elseif (!
    mysql_select_db('article'$conn)) {
        
    trigger_error('Invalid database name');

    $sql 'SELECT id, title, content, author, date FROM article';
    if (!
    $resource = @mysql_query($sql$conn)) {
        
    trigger_error('Invalid query : ' $sql);

    ?>
    <html>
    <head>
    <title>Article List</title>
    </head>
    <body>
    <h1>Article List</h1>
    <?php if (mysql_num_rows($resource) == 0) {  ?>
    <p>There are no articles.</p>
    <?php } else { ?>
    <table>
      <tr>
        <th>Title</th>
        <th>Author</th>
        <th>Date</th>
        <th>Action</th>
      </tr>
      <?php while ($record mysql_fetch_array($resourceMYSQL_ASSOC)) {?>
      <tr>
        <td><?php echo $record['title']; ?></td>
        <td><?php echo $record['author']; ?></td>
        <td><?php echo $record['date']; ?></td>
      </tr>
      <?php ?>
    </table>
    <?php ?>
    </body>
    </html>
    Fairly basic, no surprises. Couldnt really get this run much faster.

    Now if I add a data access layer, I dont have to worry about mysql connections and errors on every page. I can also change the database without going through every page on my site and changing every line with a mysql function.
    PHP Code:
    <?php
    require_once('MySqlDataAccess.php');
    $dbConn = &new MySqlConnection('localhost''article''''');
    $sql 'SELECT id, title, content, author, date FROM article';
    $recordSet $dbConn->executeQuery($sql);
    ?>
    <html>
    <head>
    <title>Artile List</title>
    </head>
    <body>
    <h1>Article List</h1>
    <?php if ($recordSet->size() == 0) {  ?>
    <p>There are no articles.</p>
    <?php } else { ?>
    <table>
      <tr>
        <th>Title</th>
        <th>Author</th>
        <th>Date</th>
      </tr>
      <?php while($recordSet->next()) { ?>
      <tr>
        <td><?php echo $recordSet->get('title'); ?></td>
        <td><?php echo $recordSet->get('author'); ?></td>
        <td><?php echo $recordSet->get('date'); ?></td>
      </tr>
      <?php ?>
    </table>
    <?php ?>
    </body>
    </html>
    This script is now takes marginally longer to execute however, I can write it marginally faster. The time saved adds up over the amount of pages in the application.

    Ive noticed that I use the same sql query to get the article list on many pages. So I add a Data Source layer, and I can call a function on an object each time I need the list of articles.

    I replace this code:
    PHP Code:
    require_once('MySqlDataAccess.php');
    $dbConn = &new MySqlConnection();
    $sql 'SELECT id, title, content, author, date FROM article';
    $recordSet $dbConn->executeQuery($sql); 
    with this code:
    PHP Code:
    require_once('ArticleTableDataGateway.php');
    $articleTDG = &new ArticleTableDataGateway();
    $recordSet $articleTDG->findAll(); 
    The page is now marginally slower to execute.

    Now I notice that each page of my site uses the same structure (dtd, head, meta tags, nav etc) for the html page. So I decide to add a template structure/engine.

    The code now looks like this:
    PHP Code:
    <?php
    require_once('ArticleTableDataGateway.php');
    $articleTDG = &new ArticleTableDataGateway();
    $recordSet $articleTDG->findAll();
    $tpl = new Template('main.tpl''article_list.tpl');
    $tpl->set('title''Article List');
    $tpl->set('recordSet'$recordSet);
    $tpl->render();
    ?>
    Ill leave the templates to the imagination.

    The page runs slower again, but I now can use the main.tpl for every page.

    I could continue on with more to add to this that will make building a website easier and quicker to do but in the end it will always be slower to execute the script. For me, the development time saved orginally, when you want to add features and when bugs appear outweighs the difference in execution time of the script.

    Note: caching this page would now be quite easy. Using a cache in php when using OO will make up for any difference in execution speed.

  15. #65
    SitePoint Zealot Selatos's Avatar
    Join Date
    Aug 2002
    Location
    USA
    Posts
    144
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yes, thats the beauty of templates, and if you look at what Widow Maker and I were discussing earlier, the code for a Template engine that works in a very similar fasion is posted. That said I still wouldn't want people to steal my code, its posted for reference purposes, to see how someone else did it. That and if it wasn't mine, I wouldn't really want to use my own code .

    Widow Maker--Upon re-rereading, I saw that you are using the MVC pattern. I don't personally like this pattern in PHP, because there is so little for the controller to do(just creates objects for you in your example), and the code in the execute() function seemed to be very static(would require minor edits with each site). I believe that in this case, MVC just adds an unnecessary layer of complexity by introducing another object & function interface and moving the new operator into another function. I would personally prefer to just create the object myself rather than have the controller class do it and return it, or if perhaps there is some sort of batch work(ie lines of initialization calls that are always the same) that I can assign to it, then I might consider using it. But if I will always have the same init calls, why not just put them in constructor?

  16. #66
    SitePoint Evangelist Andrewaclt's Avatar
    Join Date
    Dec 2003
    Location
    Raleigh, NC
    Posts
    535
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Austin_Hastings
    The one where he says this, about two sentences above the code?


    Yeah, it violates a lot of things. But it's a primer in PHP syntax. Give a writer a break, eh?

    =Austin
    I was asking for clarification and asking for an example of what would be a good method for this, I know hardly anything beyond basic oop concepts and was just trying to figure out were to go next...

  17. #67
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Brenden Vickery
    This script now takes marginally longer to execute ...
    It wouldn't be fair to compare an OOP solution with lots of extra features with a simple procedural one without these features - perhaps that's not what you intended.

    For example, you'd have to compare a non-OOP db layer (implemented with simple fn wrappers) to one implemented with OOP. It should be obvious, given both are well-written, that any differences would be minute (and completely overwhelmed by query execution times).

    In any case it's not that simple, as Lastcraft has pointed out.

  18. #68
    SitePoint Addict
    Join Date
    May 2003
    Location
    Calgary, Alberta, Canada
    Posts
    275
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff
    It wouldn't be fair to compare an OOP solution with lots of extra features with a simple procedural one without these features - perhaps that's not what you intended.
    Not what I indended. In the simple example I gave using OOP will be minutely slower even if you only add the minimum amount for the code to run to the db wrapper etc.

    Quote Originally Posted by McGruff
    In any case it's not that simple, as Lastcraft has pointed out.
    I realize that whats being discussed is more along the lines of complex domain/application logic. I would think that alot of the time the same theory will apply though, that using OO will minutely increase the execution time although significantly decrease the development time.

    That said, Ive never tested this going from a complex procedural script to a complex OO script. I guess Marcus' experience with OO being faster would have to do with procedural code creating new variables in memory where the OO version didnt..? Somehow the procedural version called more functions? I can see how OO would be faster than procedural but am having a hard time writing code to reproduce it. What are the circumstances that cause OO to be faster?

    Either way no one should be writing complex scripts using a procedural style so you can get what you think will be a performance gain. Write it using OO and defactor it if you need to. (When I say defactor I mean the opposite of refactor. What would the correct term be?) It will kick you in the *** writing procedurally later when you want to change it, you will have more bugs, and it will take longer.

    Quote Originally Posted by Austin Hastings
    No. I think you've missed my point, here: The 'trap' behing PHP4+OO is that you have to learn 'special' skills to do OOP in PHP4. Not just 'learn how to do OO', but 'Learn how to do OO in such a way that your internal OO-bogometer does not explode, and at the same time PHP4 performance isn't terrible.'

    That's a tall order in its own right. The general lameness of PHP4's OO implementation doesn't help.
    Everything youre saying about PHP4 I would apply to writing OO with PHP5. You can bloat the php5 code as much as you can with php4 although php5 will handle it better.

  19. #69
    SitePoint Wizard Mike Borozdin's Avatar
    Join Date
    Oct 2002
    Location
    Edinburgh, UK
    Posts
    1,743
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Selatos
    well, the only things that I don't like about php4 OOP include the lack of overloading functions, and then no support for full serialization. I don't know if either of these things have been added in PHP5.
    ]

    Unfortunately, PHP5 stiil doesn't support function overloading

  20. #70
    public static void brain Gybbyl's Avatar
    Join Date
    Jun 2002
    Location
    Montana, USA
    Posts
    647
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yes it does, you just have to know how...
    Ryan

  21. #71
    SitePoint Wizard Mike Borozdin's Avatar
    Join Date
    Oct 2002
    Location
    Edinburgh, UK
    Posts
    1,743
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Gybbyl
    Yes it does, you just have to know how...
    If you mean something like this:

    PHP Code:
    class SomeClass
    {
      function 
    someMethod ()
      {
         switch ( 
    func_num_args () ) {
            case 
    1:
               return 
    _someMethod1 func_get_arg ) );
               break;
            case 
    2:
               return 
    _someMethod2 func_get_arg ), func_get_arg ) );
               break;
         }
      }

    Then PHP 4 also supports that

  22. #72
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by Brenden Vickery
    I guess Marcus' experience with OO being faster would have to do with procedural code creating new variables in memory where the OO version didnt..?
    'Fraid not. If you do milisecond timings you will probably find that accessing a global is faster than a static which is faster than a static function return. Isolated this way it will be a factor of two or more slower. Isolating it in this way is pretty dumb though. One point is that this is totally swamped by the script loading time at least.

    If OO causes you to write less code then you actually win even on this. Initially OO code is about 15% bigger, but the higher level of factoring starts to kick in once the client code is using the classes. Unfortunately the higher level of factoring also means that you will likely require more files for a simple script. I think this is why the heavier OO users also favour bytecode caching solutions or are very careful about their require_once's.

    The script execution time is almost always swamped by file access and DB access calls. They in turn will get swamped by network calls. For a script to do anything useful you would have several of these and speeding these up will produce a bigger win.

    OO makes it easier to factor the code. Better factored code makes it easier to employ caching, code generation, lazy loading, query batching, adding C modules, replacing slow subsystems, lookup tables, load balancing, DB caching and...er...being careful about your require_once's. All of these will give order of magnitude improvements if they are the current bottleneck.

    If you want to optimise a system, rather than just tweak source code, you want to do it from an OO codebase. That's why OO code ultimately wins.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  23. #73
    SitePoint Evangelist Andrewaclt's Avatar
    Join Date
    Dec 2003
    Location
    Raleigh, NC
    Posts
    535
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Mike Borozdin
    If you mean something like this:
    Then PHP 4 also supports that
    No support for multiple contructors then?

  24. #74
    SitePoint Zealot Selatos's Avatar
    Join Date
    Aug 2002
    Location
    USA
    Posts
    144
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yeah....thats too hackish for me....I would really prefer being able to have something more like this:
    PHP Code:
    class SomeClass {
    function 
    SomeClass($a$b$c) {}
    function 
    SomeClass($a) {}
    function 
    SomeClass($a$b) {}

    You know, real function overloading.

    By the way, I changed my mind about the Controller class. I will have one, but it won't be solely to control my Template & Fragment classes. I have a static method in a User class that I wrote, that I feel would fit better in a controller class, because it's only purpose is to construct the User class in a certain way. I'll probably find other things to do with it too, I'm sure there'll be a lot for me to control once I take these classes past the "design objects for various uses" stage and utilize them in a project of sorts. I still don't like MVC very much, nor do I really see its purpose in PHP, but I figure "everyone else uses it, theres gotta be a reason?"

  25. #75
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by Austin_Hastings
    Let's not forget the basics:

    Object-Oriented Design, Grady Booch
    I also forgot Refactoring by Martin Fowler (doh).

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things


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
  •