NYCPHP Meetup

[Paul A Houle]

David Krings wrote:
>
> So yes, there is a good possibility that the script using the redirect 
> never generates any output. BUT, some craft their applications using 
> only a few files that each are a huge switch statement with various 
> blocks of code. In those cases the first block can very well generate 
> output whereas the second block has the redirects. It is just that 
> when the second block gets called the first block is not executed. So 
> it doesn't matter what comes first within the script, but what 
> ultimately gets sent to the browser first.
>
    Formalize this and you've got the paradigm that is (mis)-named MVC.

    Most web apps should (i) process input,  (ii) think,  then (iii) 
display something.  The thing that gets displayed is called a "view",  
and one of the jobs of the "controller" is to display a different "view" 
depending on what the application thought in stage (ii).  In a good 
system,  the controller is able to surround a "view" with a "layout" 
(visual shell:  all of the chrome that goes at the top of the page,  on 
the side and on the bottom) or be able to do a redirect,  or suppress 
the "layout" in case we want to send back,  say,  JSON or 
comma-separated text as an output.

    I think the roles of the controllers and views are non-controversial 
at this point,  but the role of the "model" is more controversial.  I 
like to call this architecture CAV (Controller-Action-View) since it 
reflects the organization of the code from the controller's viewpoint:  
the controller decides which action code to run,  the action code 
recalls data from the database,  changes data in the database or both,  
and then the controller displays a view.

    Although frameworks like Rails,  Symfony and CakePHP have promoted 
these ideas,  they may have also slowed the understanding of these 
ideas.  (We think they're a property of a specific,  complex,  product 
rather than a self-evident truth.)  A "micro-framework" that implements 
a powerful and complete controller can be implemented about 50 lines of 
PHP;  you don't even need to use objects.

    As David mentions,  you can also implement a "controller" by using 
switch statements or conditionals:  there the "actions" and "views" are 
chunks of code that are inside the switch blocks.  You can get the 
functional benefits of the CAV architecture this way,  but the trouble 
is that your actions and views are mixed in with the controllers in one 
big file,  and often it gets hard to maintain.  In a mature CAV 
architecture,  actions and views can be packed as individual source code 
files,  or as individual functions,  classes,  or methods.

    "MVC" frameworks add all kinds of bells and whistles to this idea,  
but this is the heart of how they work.