SitePoint Sponsor

User Tag List

Page 2 of 3 FirstFirst 123 LastLast
Results 26 to 50 of 53
  1. #26
    SitePoint Wizard samsm's Avatar
    Join Date
    Nov 2001
    Location
    Atlanta, GA, USA
    Posts
    5,011
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    By the way, the underscores come from copying text from the pretty [php] displays aon these pages. Quote the selection you want and select text from the textarea and there won't be underscores. I think

    ... just following along with interest ...
    Using your unpaid time to add free content to SitePoint Pty Ltd's portfolio?

  2. #27
    SitePoint Member
    Join Date
    Dec 2002
    Posts
    16
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Originally posted by HarryF
    Great post Sid! Was typing while you posted...



    It's really Vincent you have to thank for pointing it out but basically when you write purely procedural code, you probably never have this problem, as you use mysql_fetch_array() on each row then spit our the results into HTML straight away.

    When you start messing with classes though, it's common to load the whole lot into an array then pass everything to the next class to render HTML - that's alot of data in memory.

    If you look at Vincents Eclipse, he makes sure that never more than a row at a time is called from the database. I've explained it again here - look for explaination after the DataAccessResult class.



    That's exactly it. It might be worth research Iterator patterns or examine Eclipse.


    Please don't take that as criticism. Really like your concept - treat all data sources as being the same.

    Critiques are good, sometimes.

    This could be an alternate way to use it:

    PHP Code:
    # For file access;
    $pointer DataSource::init("thisfile.txt");

    # -- Then
    $contents DataSource::readall([I]$pointer[/I]);

    # -- Or
    while ($row DataSource::read($pointer))
    {
    print_r($row);}


    # SQL statement;
    $sql "select * from test;";

    # Database connection options;
    $options = Array("user"=>"***","password"=>"***","database"=>"dbtest");

    # MySQL connection;
    $pointer DataSource::init($sql,$options,DS_TYPE_MYSQL);

    # --- or for postgresql;
    $pointer DataSource::init($sql,$options,DS_TYPE_PGSQL);

    while ( 
    $row $DataSource::read([I]$pointer[/I],DS_TYPE_MYSQL) ) {
        
    print_r($row);


    Right now, I'm not sure if I'm going to change it, because I plan to make my datasource class an extension. Also, I think, with that and my Odan script both being compiled, any memory issues will become smaller, because it would execute faster thereby releasing the used memory sooner. A stress test will be the judge though.

    I'm not writing it as if it was a PHP script. I'm writing it as a proof-of-concept for the language that I'll become.

  3. #28
    SitePoint Member
    Join Date
    Oct 2003
    Location
    Silkeborg, Denmark
    Posts
    16
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Very nice post freakysid, it really got me thinking.

    I've been coding PHP for the past 2 years or so and finally decided to learn OOP some week ago or so. I've been reading almost constantly since, but haven't produced much code yet - just some cheap examples. Now I want to code a rather large application, and I too don't know where to start. I've read among other things about MVC, but it is hard to transfer the theory into a real application. I would be really happy if you could post those links you were talking about - those about OOP in general.

    Also I often see references to large frameworks. Is that something I should use, or should I just start out coding whatever I need myself? And, how *do* you use these frameworks in general?

    EDIT: Maybe some links to other threads like this one, would help a lot.

    Thanks
    Last edited by raz0; Oct 15, 2003 at 10:14.

  4. #29
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hello, have a look at these search results ? They'll help you along the way; I still go back to them every now and again just to refresh my memory (which is getting worse)

    http://www.sitepointforums.com/searc...earchid=340272

    Enjoy

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

    How did this one slip by for so long ?

    Quote Originally Posted by HarryF
    - the argument "design is dead" probably holds true for programming these days.
    Cough, splutter, ...

    Ok, I have rolled my sleeves up and kicked the cat off of the keyboard, and I now realise that this is not such an easy point to deal with.

    If you mean that you can reach into the bookshelf and pluck the solution out of your favourite patterns book, then you have a point.

    However it is a bit like saying that because bolts and rivets exist, joining two pieces of metal involves no design. That's true, but it simply pushes the lowest design threshold up to the level of why we are joining metal together. There will also be the decision of which joining method is best for the situation (rivets and bolts have different trade-offs) and the possibility of novelty (glue). That the decisions can be described at this level (patterns) means that design methods can be discussed and improved, which is what is happening now. I would call that a golden age of design.

    There is another attack on design coming from the "Test Driven Development" circles.

    That is your test cases or use cases define the design, so you simply keep coding until your tests pass. The core plan is that you do the simplest thing that could work to pass the first test. Then you add another and refactor until that test passes and so on. The result should be the leanest (and so best) design that can do the job. The catch is that this is an evolutionary or hill climbing algorithm. You can accidently climb a local hilluck and get completely stuck. Even Kent Beck, when writing the TDD book, had to start again four times! You also have continuous design anyway at the refactoring points. I am no fan of big up front design, but am in the Extreme Programing camp. Even Extreme Programmers, who usually use TDD, have design sessions on CRC cards or work with a "metaphor" at least.

    Anyway, enough philosophy, here is an example...
    PHP Code:
    class DatabaseConnection {
        function 
    DatabaseConnection($user$password, ...) { ... }
        function do(
    $sql) { ... }
        function &
    query($sql) {
            if (
    $result $this->_execute($sql)) {
                return new 
    ResultSetIterator($result);
            }
            return 
    false;
        }
    }

    class 
    ResultSetIterator {
        function 
    ResultSetIterator($result) { ... }
        function 
    next() {
            if (
    $this->_result) {
                if (!(
    $row $this->_fetchRow($this->_result))) {
                    
    $this->close();
                    return 
    null;
                }
                return 
    $row;
            }
            return 
    null;
        }
        function 
    close() { ... }

    This iterator solution is so idiomatic in PHP that it is hard to believe that there is any other way of doing things...

    PHP Code:
    class DatabaseVisitor {
        function 
    DatabaseVisitor($query) { ... }
        function 
    getQuery() { ... }
        function 
    acceptRow($row) { ... }
    }

    class 
    DatabaseConnection {
        function 
    DatabaseConnection($user$password, ...) { ... }
        function 
    query(&$visitor) {
            
    $result $this->_execute($visitor->getQuery());
            while (
    $row $this->_fetchRow($result)) {
                
    $visitor->acceptRow($row);
            }
            return !
    $this->isError();
        }
        function 
    close() { ... }

    There are actually disadvantages to the iterator solution. The interface involves two classes that are tightly coupled. The objects are as well. What happens if the database connection closes before the iterator has finished? The problem is that errors have to be checked twice; once when you get the iterator and again when it finishes. How much code is out there that does not check the original connection for a premature end of the iterator? The visitor only gets called on success and the client code gets the failure result. Much easier.

    The tradeoff is flexibilty. It is easy to wrap the resulting iterator (to turn the rows into objects for example) and pass the result around the code. If you don't need the flexibility of the iterator and are running a flaky database, the visitor could be for you. It will depend on your design.

    Design is dead - long live design!

    yours, Marcus

    Edit: Just purchased another excellent book on the subject. Domain Driven Design by Eric Evans (Addison Wesley).
    Last edited by lastcraft; Oct 15, 2003 at 17:31.
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  6. #31
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    kicked the cat off of the keyboard,
    Kicked ? I'd have shoved a rocket up it's a***



    And then lit the rocket

  7. #32
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Good points Lastcraft [I was joking btw about the cat ] though myself I'd settle for functionality over flexibility ?

    The first script is what I'd use

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

    It is actually the iterator version that is most flexible, and so the most common choice for this kind of job. The visitor is tighter and has less code, but requires a little more thought in how it is used.

    How is your OO journey progressing?

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

  9. #34
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks for asking, funny that since I've went and choosen the wrong bloddy iterator eh ?

    My Obj Oriented Programming ? Umm... []

    Getting there though as always it's difficult. The hardest part for me at the moment is Layering I suppose but I'll get there; Just need to take more time to look at what's needed and how things fit together aye ?

    I'm just about there with Model View Controller;

    One hurdle as I had seen it was mixing HTML and PHP which isn't an issue now that I can use the DOMXML extension to a greater degree than before

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

    I have never so much looked for layering as found that it comes about naturally from breaking things down into the smallest possible jobs. Once different parts of the system have their own responsibilities and they make sense, you are done. Are you working alone? You get clearer designs when someone asks you to explain them.

    As for MVC, I still don't get it, at least for web stuff. Do you really need a controller for each view? That makes sense for script controllers (i.e. scripts ), but that would be a lot of subclasses if you had plug-ins to a front controller. Either that or a hefty config file.

    I kinda learned my OO from the bottom up I am afraid.

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

  11. #36
    SitePoint Evangelist
    Join Date
    Jun 2003
    Location
    Melbourne, Australia
    Posts
    440
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    As for MVC, I still don't get it, at least for web stuff. Do you really need a controller for each view? That makes sense for script controllers (i.e. scripts ), but that would be a lot of subclasses if you had plug-ins to a front controller. Either that or a hefty config file.
    This reminds me of something that Selkirk said here.
    Quote Originally Posted by selkirk
    Off the top of my head...
    • Write small methods that do only one thing.
      Write small classes that encapsulate only one concept.
      Combine your small classes with small methods in interesting ways.
      Use the decorator pattern to implement rarely used functionality.
      Use the visitor pattern to implement uncommon functionality.
      Avoid deep inheritance hierarchies.
      Split up large classes based on usage patterns. (for example, File becomes FileWriter and FileReader)
      For rarely used classes, REQUIRE files with class definitions just before you actually instantiate the class instead of at the top of the file.

    Only one of these is specific to PHP...
    ...which I took to imply that if you write a whole lot of subclasses and instantiate only those that are needed (perhaps based on the action the user is trying to take), a whole lot less code is loaded.

    A class like that which lastcraft suggests here...
    PHP Code:
    class CommentBroker 
        var 
    $_mysql
        var 
    $_auth

        function 
    CommentBroker(&$mysql, &$auth) { 
            
    $this->_mysql = &$mysql
            
    $this->_auth = &$auth
        } 
        function 
    findByPoster($poster$get) { ... } 
        function 
    add($contents$post) { ... } 
        function 
    edit($post) { ... } 
        function 
    delete($id) { ... } 

    ...has a whole lot of methods, but presumably only one would be enacted for any single page view. In fairness to lastcraft and ausurt (two of the main participants in that thread), the code did not appear bloated at all, so this isn't a criticism. Rather, it's a difference in approach or philosophy.

    I suppose it's a case of balancing file loading time (many small files rather than a smaller number of larger ones) against the amount of stuff that has to be initialized before any single action can be enacted.

  12. #37
    SitePoint Zealot
    Join Date
    Aug 2003
    Location
    Sydney
    Posts
    187
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yeh, there are a few things added in since that, but i think it turned out to be pretty good. Thanks lastcraft.

    It doesnt appear bloated at all and it will reduce in time.

  13. #38
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Once different parts of the system have their own responsibilities and they make sense, you are done.
    Good point you've made Lastcraft. Though for me it isn't so much the responsibilities of a class it's self but how the class it's self is used in the context of another class yes ? ie

    The passing to/from of data and I'm not really talking about Getters and Setters, but maybe more about how one class method can use data effectively aye ?

    Umm...

  14. #39
    ********* 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 Dr Livingston
    Though for me it isn't so much the responsibilities of a class it's self but how the class it's self is used in the context of another class yes?
    You need to talk to yourself. Well, not literally, but you need to take multiple viewpoints by pretending to be each object in turn. You say "Ok I am the Account and the Biller needs to talk to me. So now I am the Biller and as the Account passes me around I need LineItems to total. So I have to total the incoming LineItems, OK, I am the account and I have to supply LineItems in turn..."

    By thinking in conversations you are naturally dealing with OO message passing. Another useful technique is RRC cards (see the "Becky book": Roles, Responsibilities and Collaborations - Rebecca Wirfs-Brock).

    It is easier if you have someone else to talk to, though.

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

  15. #40
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It is easier if you have someone else to talk to, though.
    Folks I script for are not developers

    They're not all that interested in development either

    Maybe I should post more huh ?

  16. #41
    ********* 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 auricle
    I suppose it's a case of balancing file loading time (many small files rather than a smaller number of larger ones) against the amount of stuff that has to be initialized before any single action can be enacted.
    OK, I didn't state the case very well at all.

    The piece I have quoted from you certainly applies to reducing the loading requirements of FrontControllers to that of PageControllers. The trick is summed up as the FrontController using a class loader. When that happens having small controller classes (in files matching the action name) is a way to achieve that. No philisophical difference in this respect and I have resorted to this trick myself.

    What bothers me about MVC is the duplication of needing one View and one Controller for each page, two things per page. Controller could just be a script and View could just be a template, but still two things nevertheless. Given that a web page cannot recieve any external input after the initial request, it really makes them batch jobs. Now you don't get the batch processing crowd resorting to Model-View-Controller.

    Ok a crass analogy, but one that causes me unease.

    Now I have set myself up to reveal some stunning revelation. Regretably I don't have one . My current feeling is that Controller and View can be joined and resplit in a new way as yet unnamed. Don't know how yet...

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

  17. #42
    SitePoint Member
    Join Date
    Oct 2003
    Location
    Silkeborg, Denmark
    Posts
    16
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'm not sure I understood your example at all. Where does the _execute() method come from? and what about _request? Did you just strip them out to simplify the example?

    I am trying to write my first real OOP web page. It is going to be quite big, and I need the following:

    * Login system, restricted areas.
    * Different right for different users.
    * News system only accessible by the admin.
    * Among other things a picture gallery where you can upload images to.
    * A search where you can search for members on a lot of different criterias like name, age, location, eye color etc.

    Now how would I go about making this? Which pattern should I use? I was thinking of something like this, but I am not sure at all if this is "correct oop":

    PHP Code:
    $dbconn &= new Database($username$password);

    $user &= new User(&$dbconn$username$password);
    if (
    $user->accessLevel() == 100)
    {
        
    // display the restricted functionality
        // for instance the image gallery
    }
    else
    {
        
    // no access

    I have no idea how to make a class for the image gallery though. Also, how would I go about gererating the HTML with OOP? Should I just skip this to begin with, or what? A little hint would help me a lot!

    EDIT: Just an example to explain how the different classes would work. It actually looks much like one of the previous in this thread *shrug*

    PHP Code:
    class Database
    {
        var 
    $host;
        var 
    $username;
        var 
    $password;
        var 
    $dbname;
        var 
    $link;

        function 
    Database ($host$username$password$dbname)
        {
            
    $this->host $host;
            
    $this->username $username;
            
    $this->password $password;
            
    $this->dbname $dbname;
            
    $this->connect();
        }
        
        function 
    connect()
        {
            
    $this->link mysql_connect($this->host,$this->username,$this->password);
            
    mysql_select_db($this->dbname);
        }

        function 
    query($sql) { ... }

    }

    class 
    User
    {
        var 
    $dbconn;
        var 
    $username;
        var 
    $password;

        function 
    User(&$dbconn$username$password)
        {
            
    $this->dbconn &= $dbconn;
            
    $this->username $username;
            
    $this->password $password;
        }
        function 
    validateUser(..) { ... }

        function 
    accessLevel()
        {
            
    $result $this->dbconn->query("SELECT accesslevel FROM users WHERE username = '$username'");
            return 
    mysql_result($result00);
        }

    Of course there is lots of space for improvements such as verification etc., but what do you think so far? Note I haven't tested it at all, just wrote it here while thinking. What do you think about the accessLevel method? Is it "incorrect" OO to use mysql_result() there?
    Last edited by raz0; Oct 23, 2003 at 07:47.

  18. #43
    No. Phil.Roberts's Avatar
    Join Date
    May 2001
    Location
    Nottingham, UK
    Posts
    1,142
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You don't use & in the class/function call, just the original declaration.

  19. #44
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Why are you using INTEGERs for validating a users access level ?

    There are much better methods to use such as Roles Based Authentication which is really easy to implement and maintain

    As which patterns you use, if you cannot determine which pattern to use then I'm getting the feeling you've got the wrong idea about Patterns altogether.

    Before you even consider a pattern, first you need to identify a problem, in this regard I do not mean a bug related problem but a refactoring related problem yes ?

    You need also to consider the design you originally used on your script and what advantages/disadvantages there were at the time to using the design you used to script [develop] by.

    Only then you consider looking at patterns as I see it yes ? Which pattern you use is by which problem you are faced with, which in most cases is several and there may not be a pattern available to completely solve an issue.

  20. #45
    SitePoint Member
    Join Date
    Oct 2003
    Location
    Silkeborg, Denmark
    Posts
    16
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Okay, so should I just continue like I am doing now and forget about patterns to I am more experienced with OOP, or is what I am doing now going in the complete wrong direction?

    The reason why I use integers is because I only need 2 or 3 different kinds of users What do you mean by "Roles Based Authentication"? You mean like storing the different kinds of user levels/roles and their specs in a database?

    You need also to consider the design you originally used on your script and what advantages/disadvantages there were at the time to using the design you used to script [develop] by.
    The design I originally used on my script? What do mean? Please clearify

    Also, could you cover frameworks briefly and tell me when they should be considered? I mean, should _I_ consider one, or just code whatever I need myself?

    Thanks in advance
    Last edited by raz0; Oct 23, 2003 at 09:25.
    .: raz0
    .: email: raz0[at]worldonline[dot]dk
    .: webpage: http://raz0.zalon.dk/

  21. #46
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    No I wouldn't forget about Design Patterns as they are going to be an important part of web development and a required learning and a knowledge of Design Patterns will not only help you develop better but increase your chances of work in the future.

    But what I suggest is that for the moment forget about trying to develop with Design Patterns and just study them instead ?

    I'm by no means an expert though I'm studying Design Patterns and I would highly recommend Martin Fowler's Book; Do a quick search on Amazon by this Author to find the book.

    On your other points before you develop do you design yes ? ie Do you plan how your going to develop your script... What problems are you taking into consideration that you might run into - If so, what solutions do you arrive at ?

    What are the weak and strong points of a given solution ? Maybe there are alternatives to this solution that you could look at for example ?

    For example, just by implementing a Design Pattern doesn't automatically mean that the script is going to be better, not if the original design of the script is questionable if you see what I mean ? You may in fact end up using the wrong Pattern altogether and make matters worse

    As to Role Based Authentication, you have an Administrator for example ? This administrator has x permissions, possible a lot more than a role for example, an Editor who can only edit articles yes ?

    An Editor wouldn't have permission to modify templates for example... Nor to modify user details either yes ?

    Do a search on Role Based Authentication here at this Advanced PHP Forum to see what that brings up ok ?

  22. #47
    SitePoint Member
    Join Date
    Oct 2003
    Location
    Silkeborg, Denmark
    Posts
    16
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Okay, I see what you mean. This is apparently a much larger subject than I had expected. One thing that would help me now, is if any of you could tell me if I am going in the right or wrong direction with my current code, and if I am way out, come with suggestions to improvements.

    Untill now I have just been reading, but it is quite hard for me to just keep on reading without producing anything myself. All these technical terms like 'factory methods', 'MVC pattern' etc. are kind of hard to remember when you have never actually used them, if you know what I am saying. But enough whining from me , looks like it is the only way forth.
    .: raz0
    .: email: raz0[at]worldonline[dot]dk
    .: webpage: http://raz0.zalon.dk/

  23. #48
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It's never easy... Topics to consider are Software Layering which you should look at; Currently reading Martin Fowler's book just now which has some talk about Layering.

    Look at OOP script from this forums which does discuss issues related to OOP and web development which kind of leads to thinking about new and better methods of development as I see it

    As to your scripts it looks like you could be on the right track though you really need to plan more; I suffer from this a lot as well;

    I tend to write the class skeleton first and plan from there but this isn't always the best route to take.

    Read the 'Best Practices' discussion going on at the moment in another thread btw

    Good Luck

  24. #49
    SitePoint Member
    Join Date
    Oct 2003
    Location
    Silkeborg, Denmark
    Posts
    16
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yeah, I guess trying to create a "perfect" application in your first attempt with OOP is kind of pointless. There is no way on earth that is possible - seems like it takes years to become a good OO programmer

    Quote Originally Posted by Dr Livingston
    Read the 'Best Practices' discussion going on at the moment in another thread btw
    Consider it done

    Quote Originally Posted by Dr Livingston
    Good Luck
    Thanks, I really appreciate your help.
    .: raz0
    .: email: raz0[at]worldonline[dot]dk
    .: webpage: http://raz0.zalon.dk/

  25. #50
    SitePoint Evangelist
    Join Date
    Jun 2003
    Location
    Melbourne, Australia
    Posts
    440
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    What bothers me about MVC is the duplication of needing one View and one Controller for each page, two things per page. Controller could just be a script and View could just be a template, but still two things nevertheless. Given that a web page cannot recieve any external input after the initial request, it really makes them batch jobs. Now you don't get the batch processing crowd resorting to Model-View-Controller.
    Hmm... I don't know what you mean by 'batch job' in this context, but...

    Is there necessarily anything wrong with having one view per page? Presumably different pages display different things. For example, a user registration form would look different from a page displaying user details even though both contain (almost) all of the same information.

    OTOH, a user registration form would look almost (if not exactly) the same as a form for editing user details. So perhaps some sort of initialization is required to determine which of a limited number of views is required for a specific page request.

    For the templating crowd, it's possible to place all the views of, say, a news "module" into a single html file and separate views into blocks, one of which would be loaded and manipulated for the corresponding request. However, that's a lot of HTML that isn't used and still has to be held in memory (that is, in the templating object). So that's kind of like implementing methods for different page requests in the same class.

    I'm not opposed to sharing views, just loading more unused stuff than is absolutely necessary.


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
  •