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.
_______________________________________________
New York PHP User Group Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
http://www.nyphp.org/show_participation.php
