SitePoint Sponsor

User Tag List

Page 2 of 3 FirstFirst 123 LastLast
Results 26 to 50 of 65

Thread: RFC on MVC

  1. #26
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Azmo
    IMO web applications don't have user interfaces:
    But they do have interfaces. It hardly matters how directly they are tied to the user or even IF they are tied to the user. How directly is a GUI tied to the user anyway?

    Quote Originally Posted by Azmo
    Experience has shown that wings work really well on airplanes. That doesn't mean we should stick them on submarines as well....
    This submarine has wings.

    Quote Originally Posted by Azmo
    The problem is that many people now seem to believe that MVC is the only way to achieve 'separation'
    Yes. that is a problem. People call anything that attempts this separation MVC. Thats why I tried to firmly root things in the input-processing-output paradigm. I think its the only way of teasing sanity out of MVC. Otherwise, the description would be too amorphous to be useful.

    One could just as easily do a description of MVC based on a model-UI-mediator paradigm of MVC. However, I don't think that both paradigms can coexist in the same description and still provide clear meaningful guidance.

  2. #27
    SitePoint Zealot
    Join Date
    Jun 2003
    Location
    Elsewhere
    Posts
    107
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Widow Maker
    Such as ?
    Among others:
    • Form validation - A PHP application receives a list of parameters along with each request. Whether these originate from a regular URL or a form is completely irrelevant. Forms are no more than HTML (document) structures which can be rendered by client software in such a way that they allow a user to visually manipulate the parameters sent along with the next request. Parameter validation exists, form validation doesn't.
    • Views - HTLM documents are NOT interactive. User interaction may be created by the client software, but it is no direct concern of the web application. And the term View implies a visual presentation of the returned Document. But an RSS aggregator doesn't have any eyes, does it? Interactive Views as described by MVC simply don't exist in web applications.
    • Composite Views - Very hard in MVC, dead easy if you stop thinking of them as Views.
    • Placement of parameter handling - Does this belong in the Controller or in the Model? This has worried a lot of people for a long time, and they've finally decided it's a cross-cutting concern. Again, things become a lot easier when you realize that some of the request parameters are used by the Action, and some are used by the main Block. Advantage: nobody has any strong beliefs about how Actions and Blocks should work together, but they do know the restrictions that MVC imposes. These restrictions will kill you, because they weren't intended to be used in web application architectures.


    Quote Originally Posted by Widow Maker
    [ MVC ] is enough to get by until something more concrete is put forward.
    In the past year I've been reading quite a lot about patterns, MVC, and all that stuff. And even though there seems to be some unhappiness and worry about MVC, hardly anyone is really trying to find an alternative.

    'Model-View-Controller' has become the de-facto language for discussing web applications. There seem to be quite a number of people who are not happy with it, and those who say they made MVC work have often made changes to the pattern. But if we want an alternative conceptualization / pattern / language, we'll have to start from scratch. What really is a View? What is the Model? Has anyone even given any thought to what web applications really are? Let's try to come up with definitions and terminology that better describe what's going on, and what you're trying to do. Only then will we be able to define the problems and concerns in other ways than 'MVC'.

    Quote Originally Posted by seratonin
    Fundamentally, how is that much different from a desktop application where a user clicks a button and the application does something in response?
    Quote Originally Posted by Selkirk
    But they do have interfaces. It hardly matters how directly they are tied to the user or even IF they are tied to the user.
    The problem as I see it, is that many web developers are trying to build desktop applications in PHP. So they completely disregard the network between the application and the client software. They ignore the existence of client software. They ignore the server software. They ignore the fact that the client software generally doesn't know what the content it's displaying means. They ignore the fact that the User (if there even is one) interprets the displayed data mostly based on the visual structure of that data, and the context in which it is displayed. They've never even realized that the same data could easily be displayed in a different way, and that this would cause the User to interpret it as a different application. They ignore the fact that request-based applications have an extremely short lifespan, and that most objects only use a limited amount of functionality, so that a Domain Model may cause severe bloat for each script call. MVC causes people to think about web applications in ways that don't resemble web applications. And that can't be right....

    And yes. You can build web applications using MVC. But that doesn't mean you should. I'm not saying the pattern leads to bad architectures or anything, it just leads to a misunderstanding of the applications being written.

    Anywho, I've been ranting about MVC for some quite time now, and I'm either not formulating my arguments well, or maybe I'm just being too stupid to see reason. Maybe no-one is really listening, or giving thought to what I'm saying. These posts are costing me a lot of time, and it feels to me like I'm fighting an entire community (there's little support for people who don't believe in MVC). So I'll just go back to working on my own little framework / application, and let you lot sort it all out by yourselves.

    Azmo.

  3. #28
    SitePoint Zealot
    Join Date
    Mar 2004
    Location
    Netherlands
    Posts
    138
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The term application often is directly associated with GUI application. I think this is wrong.

    There are many types of applications
    - GUI applications
    - Console (text based) applications
    - Web applications

    I believe web applications are absolutely not comparable to GUI applications. The enviroment and paradigms both are totally different.

    There are two ways you can do with this:
    1. Try to simulate GUI applications over HTTP (this is possible to some extend, although you then can better use specific frameworks for this that are written in Java. ASP.net with it's 'postbacks' is also an option)
    2. Embrace the web paradigms, and try to create a useful user interface based on hyperlinks and forms, with a little JavaScript added where needed.

    I'm definately in the second camp. The theory you need to learn for this is not MVC, but REST:
    http://internet.conveyor.com/RESTwik....cgi/FrontPage

    That said, I'm still very interesed in MVC. It's also a nice challenge to try to make a mapping of MVC to REST. I believe that such a mapping will include lots of things that need to be done at the client side via JavaScript.

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


    We are reading, and digesting Azmo

    Some interesting points you've made, such as

    They ignore the existence of client software.
    I cannot understand how someone would directly use PHP from the Desktop, other than maybe a Command Line. Personally, I'd prefer to use Java Swing for the client, and if possible, tie this in with PHP on the server side.

    This would indeed be an interesting concept with version 5 - something to think about over the next year or so, since not everyone is JSP mad, and PHP does a half decent job of things as it stands anyways

    But an RSS aggregator doesn't have any eyes, does it?
    Nope, indeed not, so trying to figure how this one, and how it fits into the MVC model isn't for the faint of heart

    What really is a View?
    Most people assume it's the web page, (but as McGruff might agree with me), I think it's rather a representation of raw data in it's self yes ??

    How this data is then manipulated, is up to the browser, or whatever it is that uses the data. It could be a browser, or it could just be a dumb terminal moniter I suppose huh ??

  5. #30
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Azmo
    Among others:
    Your arguments seem to be based on the idea that there there is no spoon. Creating artificial constructs is what we do as programmers. We do that because the constructs are useful to our thought process, not because they are real.

    There is a problem with my definition of MVC. If you accept that the purpose is to separate domain logic from the user interface, then you would expect to find a single structure in MVC that represents domain logic, the obvious one being the model. Yet, it is easy to find examples of non-domain logic that most naturally fits in the structures of the model. Thus, one of the elements of my description is wrong. Is it that the purpose of MVC is NOT to separate domain logic from the user interface? Or is it that my definition of the model is wrong?

    There is room for this idea in the input-processing-output paradigm of MVC. We have:

    input ---> (domain processing && user interface processing) ---> output

    I'm inclined to search for alternate definitions of the model, but retain the same structures.


    Quote Originally Posted by Azmo
    Views - HTLM documents are NOT interactive.
    Pixels on the screen aren't interactive, either. It is only our artificial constructs that bind mouse input to them and give them this illusion. and a useful illusion it is.

    Quote Originally Posted by Azmo
    Composite Views - Very hard in MVC, dead easy if you stop thinking of them as Views.
    they are easy if you think of them as views, too. Its the controllers that are hard.

    Quote Originally Posted by Azmo
    Placement of parameter handling - Does this belong in the Controller or in the Model?
    This is easy in the input-processing-output MVC paradigm. They are input, they go in the controller. The controller may pass them on to the model, but they first go into the controller.

    Quote Originally Posted by Azmo
    And even though there seems to be some unhappiness and worry about MVC, hardly anyone is really trying to find an alternative.
    or everyone is working on an alternative, and they all call it MVC.

    I am not saying the end of web programming is MVC, but the "struts pattern" claims to be MVC and seems to have legs. I take this to mean that it provides something useful. I know I've found the constructs of struts that I have been folding into WACT more useful that WACT without them. I certainly don't believe that struts or web MVC is the perfect structuring solution.

  6. #31
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    claims to be MVC and seems to have legs.
    But can it walk ? Run ? Maybe it's just crawling huh ?

  7. #32
    SitePoint Evangelist
    Join Date
    Dec 2003
    Location
    Arizona
    Posts
    411
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    My philosophy on MVC:

    M. Fowler says MVC works well for Web-based software applications. So I think MVC works well for Web-based software applications.

    If M. Fowler told me to jump off a bridge...



    JT

  8. #33
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yer, you'd jump off said bridge

  9. #34
    SitePoint Zealot
    Join Date
    Jun 2003
    Location
    Elsewhere
    Posts
    107
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    They ignore the existence of client software.
    Maybe I should have phrased that as:

    "They ignore the existence of separate client software."

    Most people seem to think that their PHP scripts display HTML to a user, but in reality there are a lot of layers between web application and client software (and possibly the user). If you disregard these layers, you'll likely end up with an incorrect understanding of web applications.

    Quote Originally Posted by Selkirk
    Your arguments seem to be based on the idea that there there is no spoon
    No, there definitely is a spoon IMO. But my point is that a lot of people are having problems with the spoon; they're finding it very hard to eat soup with it, except thick pea soup or noodle soup. So now they're saying that eating soup with a spoon itself is hard, and that for some inexplicable reason, it's quite easy to stick a piece of meat on a spoon.(!!!)

    I'm trying to get people to really look at the spoon, because I'm worried we may have accidentally been eating soup with something that might be better called a fork.....

    If you call a spoon a spoon, and you call a fork a spoon as well, there will always be a rather high amount of confusion. And some people will argue that spoons and forks are similar in many ways, and that you can stretch the definition of a spoon to fit a fork, but that's not the point. When we're all talking about spoons when we should be talking about forks, then people will always keep some residue of their idea of a spoon in the back of their heads.

    MVC was intended to be used within desktop applications. Web applications are not desktop applications. The concerns of these to types of application are similar in some respects, but completely different in others. Major is issues of one are minor issues for the other. When you keep treating web applications as 'sort-of' desktop applications, and use a vocabulary intended for desktop applications, then you're gonna get confused at some point. Basically, it's harder to understand forks when you keep talking about spoons.

    input ---> (domain processing && user interface processing) ---> output
    I would prefer:

    input (request)---> domain processing (web app) ---> output (response + document) ---> content processing (client software) ( ---> user interface )

    or everyone is working on an alternative, and they all call it MVC.
    Yet another reason to stop thinking about web applications in terms of MVC; it's becoming a showcase of terminology dilution. Start calling everything MVC, and it will mean anything to everyone. That's rather opposite to the original reason why design patterns were created: to help people talk about software solutions.

    MVC is the perfect structuring solution.
    I'm trying to say it's a horrible vocabulary, because it bears no relation to the concerns of the problem domain, it's limited to three obscure and misleading terms, and these terms mean different things to many people.

    Azmo.

  10. #35
    SitePoint Zealot
    Join Date
    Feb 2003
    Location
    Virginia
    Posts
    143
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    input (request)---> logic (process)---> output

    Then apply a scope (circuit, platform, os) or (function, class, abstract)... Depending on what scope one is speaking of the formula still makes sense.

    The problem is that people skip in and out of scopes when detailing what they mean, so it gets confusing to go from function level to design level to application level.. See?
    it's becoming a showcase of terminology dilution. Start calling everything MVC, and it will mean anything to everyone. That's rather opposite to the original reason why design patterns were created: to help people talk about software solutions
    Spot on.

    In replacement of MVC does anyone have a more concise way of expressing analysis and design type ideas - ones that wont take too long to post to a message board?

  11. #36
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    expressing analysis and design type ideas
    UML springs to mind, but a lot of people cannot really understand this, myself included of course

    Psuedo coding, or structured english is another way of expressing program design and flow, which I'm more in favour off actually

    Or maybe I've just missed the point of your terminology huh ?

  12. #37
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Is:

    input ---> (..etc..) ---> output

    .. a good way to summarise a php app?

    To me that's too focussed on the client page - just one item on the menu.

    Instead:

    input-->
    execute action1
    execute action2
    execute action3
    ..etc

    (Some logic steps might be sprinkled amongst the actions).

    Actions might separately write to the model or read from the model (eg views). They might set some kind of application state such as starting a session & setting some kind of user access vars. There could be several kinds of viewable output - not just the client page.

    Strictly speaking perhaps client output shouldn't be required by the design at all although it's hard to think of a request that wouldn't involve even a simple "task completed successfully" type of page.
    Last edited by McGruff; Apr 30, 2004 at 15:47.

  13. #38
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    McGruff - on the last point you've noted,

    although it's hard to think of a request that wouldn't involve even a simple "task completed successfully" type of page
    Something like a Command Line wouldn't require a View, no ?? Another point, is that you could involve the MVC pattern within a Batch process even...

  14. #39
    SitePoint Zealot
    Join Date
    Feb 2003
    Location
    Virginia
    Posts
    143
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Widow Maker
    UML springs to mind, but a lot of people cannot really understand this, myself included of course
    I really like Ambler's writting style.
    http://www.agilemodeling.com/style/

    Very nice reference (save it to fav):
    http://www.dotnetcoders.com/web/lear...l/default.aspx

    Nice primer but it goes fast:
    http://sunset.usc.edu/~neno/teaching/s99/March23.pdf


    PS: If I ever need a lung.. Dont forget me now

    Quote Originally Posted by McGruff
    Is:

    input ---> (..etc..) ---> output

    .. a good way to summarise a php app?
    In scope I think it's the most logical way php. Am I being clear on what I mean by scope? Anyhow, I agree, that sumerizing the entire program with "input -> ? -> output" would be laughable at best. You saying I'm selling snake oil?hehe.. sssss

  15. #40
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    My lungs are no use to anyone anymore Full of tar from smoking 80 a day

    Stress of modern day living as I see it

  16. #41
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Following my sudden urge to randomly respond to every quote I could find and had something to say about...:

    I added action chains to WACT, BTW and found them to be a big improvement over the single action style.
    I'm curious, how do you define Actions, and thus Action Chains? Are Actions are objects in the domain model or business layer of an application that carry out work on the domain model ('the business logic')? Or are they like PageControllers which contain logic to display views?

    One thing that I've been experimenting with is creating a hierarchy of front controllers. My hope is to improve the decomposition of the controller part of the MVC.
    I'd say that a hierarchy of front controllers is against the definition of a front controller, namely one object that receives all requests to an application.

    However, I am in favor of 'allowing' multiple front controllers for one application. Here's a part of the documentation of the FrontController equivalent of my framework. I call them EntryPoint but that name changes like every 2 weeks, so just call it a FrontController if you will

    Quote Originally Posted by Framework X Guide Excerpt
    As an example of one application that has several presentation layers, think of an application for publishing articles. Such an application would have a control panel of some sort where authors can publish articles, a website where the published articles can be read by readers and possibly an interface that allows the server to communicate with a desktop application to publish articles. These are all different presentations for the same content, albeit that each presentation layer offers different functionality to the client.

    A presentation layer is not neccessarily defined just by the format of the data that is sent back to the client, i.e. HTML, WML or XML. There may be more than one HTML presentation layer for example.

    Why multiple EntryPoints for requests for one application instead of just one (FrontController-like) entity where all requests comes in?
    Request handling involves tasks like authentication and session tracking, tasks which are 'common' to an application. But, exactly how common are these? A website that simply presents dynamic content does not need authentication, but an administration panel of that website definitely does need authentication. Both of these are part of the same application: a website CMS, but they have different '(not-so)-common' behaviour. Because the framework allows multiple Entry Points, one for each presentation layer, common behaviour can be defined per presentation layer instead of application-wide.

    OK, but why can't this semi-common behaviour be put into base classes for PageControllers?
    EntryPoints can form a pipeline out of any number of InterceptingFilters in any order, something which is not possible when the behaviour of the filters is coded into a PageController base class. By encapsulating this behaviour into separate classes instead of putting it into a PageController base class makes the request handing more flexible and reusable (which is, as some might say, more object oriented).
    Quote Originally Posted by Selkirk
    There doesn't have to be a 1:1 correspondence between model and view.
    That is the reason that the original GUI-MVC pattern was existed: to support multiple views of one model.

    Quote Originally Posted by McGruff
    Models need to talk to each other - eg a HeadHtml object (everything between the < head > tags) might want to gather a page title, custom CSS styles or some keywords from other sub-models.
    Agree with Selkirk, if that is your definition of Model, no wonder why you're so biased against MVC [Disclaimer] It's a very informal definition and probably not 100% correct but I'll propose it anyway because it is so easy to visualize[/Disclaimer]: a domain model is an object representation of the data in a database including the rules that make sure this data remains valid and behaviour that can be carried out to manipulate this data.

    Also, the term sub-models is a bit redundant. Model is a concept that is already 'plural', as in 'the model of an application'. Saying that an application has 'multiple models' or 'sub-models' simply does not make sense.

    Quote Originally Posted by NativeMind
    - Applying aggregate functions (like security, authorization, etc).
    First of all, I'd like to say that the MVC pattern does not define how to implement security and authentication: they are concepts that are orthogonal to MVC. That means that the MVC pattern doesn't care how this is implemented. Perhaps that's also a weakness.

    Secondly, I probably won't be the first to claim this, but I have proposed a solution for this in my framework's documentation excerpt above. If you're willing to accept the idea of multiple front controllers and combine them with page controllers of course.

    Quote Originally Posted by McGruff
    There could well be... My "block-models" gather data, process the data, share some of that data if need be, and basically exist to create a bunch of page vars which are echo'd out in each block-view. That may not be a complete domain model but it's all the Printer class I described needs to know about.
    From what I have learned of your interpretation/implementation of the pattern, I don't like it for the reason that your implementation causes 'control' to be distributed to these block objects. To me, that is a bit against the nature of PHP applications, where control over the handling of a request is always in one place. But that's another discussion I think.

    The corollary to this is "It is damn hard to write tests for views or actions(controllers)."
    Agreed, but you try and test the view equivalents of a non-MVC application At least with MVC you can test some things.

    The Printers which I outlined above are, I think, just views. Each printer/view is supplied with a list of objects with which to query the model and a list of whatever templates are required to present the data. They don't encapsulate MVC - just V.
    <very glad smiley>

    Thee problem with many MVC frameworks is that they reserve some of the best structuring mechanisms for themselves.
    Nobody is saying that the current MVC frameworks are the best possible implementations of the pattern (Much like today's SQL databases are lousy implementations of the relational model (another discussion subject, sorry)). Well, nobody except the framework developers of course

    Quote Originally Posted by Azmo
    Composite Views - Very hard in MVC, dead easy if you stop thinking of them as Views.
    Right. Much like what I explained about Model, View is a concept that does not need to be mapped 1:1 to one class. The concept of the View can be implemented by any number of classes.

    Quote Originally Posted by Azmo
    would prefer:

    input (request)---> domain processing (web app) ---> output (response + document) ---> content processing (client software) ( ---> user interface )
    Agree with you, but the last two items are simply beyond the scope of PHP applications, aren't they? PHP apps simply send a response to the client (browser) and how that content is processed by the client software, it simply doesn't care and doesn't have to care either. You might as well add "TCP/IP (sending over the internet)" to that list then.

    In replacement of MVC does anyone have a more concise way of expressing analysis and design type ideas - ones that wont take too long to post to a message board?

    ...
    UML springs to mind, but a lot of people cannot really understand this, myself included of course
    I doubt UML or any other tool to visualize designs has anything to do with this, what Resolution means is, I think, another vocabulary to express the problem more clearly.

  17. #42
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Just to be 100% clear, are you saying that objects which only read from a domain (and don't change it's state) are not part of the domain model? I could well have been using the term incorrectly.

    As I mentioned, I'm post-embedding now anyway. Attempts to redefine & reduce the MVC controller are perhaps pointless since it's whole purpose is to take over right from the word go. Anything else wouldn't be MVC.

  18. #43
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Captain Proton
    I'm curious, how do you define Actions, and thus Action Chains? Are Actions are objects in the domain model or business layer of an application that carry out work on the domain model ('the business logic')? Or are they like PageControllers which contain logic to display views?
    Here is an example of defining actions with WACT:
    PHP Code:
    class Preview {
        function 
    performAction(&$FormModel) {
            return 
    DEFAULT_VIEW;
        }

    This action is attached to the preview button on an input form. Actions have no inheritance requirements, they only need to implement the performAction method. FormModel is a object used in WACT known as a DataSpace. For actions, the FormModel is passed from action to action in the chain, until it is finally passed to a view object, which examines its contents and produces a response based on it.

    An action may return a value. If it does, this is used as an indicator of which view should be used to render the HTTP response. Here, we use a constant that says re-render the same view.

    Here is an example of a more complicated action:
    PHP Code:
    class AddCategory {

        function 
    performAction(&$FormModel) {
            
    $Id Category::insert($FormModel);
            if (
    $Id) {
                
    $LastRecord $FormModel;  // make a copy

                // Set up the form for adding the next record
                
    $FormModel->import(array());

                
    // Allow the view to show the last record added
                
    $LastRecord->set('Id'$Id);
                
    $FormModel->set('LastRecord'$LastRecord);

                return 
    'success';
            } else {
                return 
    'failure';
            }
        }

    Since the action is considered part of the controller, to maintain MVC, it delegates the category insertion to the model. That leaves some UI code in the action which allows another record to be input or the results of the previous record to be displayed in the view. This action will route to two possible views, one for success one for failure.

    Now, we have the Page object, which merges both of these actions into an action chain:
    PHP Code:
    class AddCategoryPage extends FormPage {

        function 
    AddCategoryPage() {

            
    parent::FormPage();

            
    $this->registerValidator(new CategoryValidator());
            
            
    $this->registerAction(new Preview(),
                array(
    FORM_POSTED'preview'));
            
    $this->registerAction(new AddCategory(),
                array(
    FORM_VALID'submit'));

            
    $this->registerView(new AddFormView("/category/add.html"));
            
            
    $this->registerAppController(
                new 
    DirectApplicationController(
                    array(
                    
    'failure' => NULL,
                    
    'success' => NULL 
                    
    )
                ));
        }


    Each registered action is checked and executed in sequence until an action returns a value other than NULL. (indicating the view which should be used.)

    array(FORM_POSTED, 'preview') is a compound condition meaning if the form has been posted and the preview button has been pressed. (technically if the POST variable preview is not null.) If the condition is true, then the Preview action is called. Since Preview always returns a view, no further actions in the chain will be attempted.

    array(FORM_VALID, 'submit') is a condition that is met if the form passes the validation tests and the submit button is pressed. performAction on AddCategory will not be called unless this condition is met.

    If no action specifies a view, the default view is re-displayed. (possibly with validation errors, etc.)

    Note that this chain of actions is alot like the chain or responsibility that a GUI app would use to determine that a mouse click at position X,Y is a click on button Z. Its just that GUI frameworks have taken over responsibility for this low level checking, while web frameworks have not, yet. (well, .net and JSF do)

    The application controller maps the logical view names returned by the actions into concrete views. Both results here are defined as NULL, which means re-display the same view. The tokens are mapped to handles. A handle can be an object. A handle for a confirmation or thank you page could be provided. A handle for an error page could be used. A handle for a redirect to another page could also be used. Notice that these application control flow issues do not require modification to the actions, only the application controller translation table.

    One benefit to breaking up the controller portion of MVC into smaller actions and a page controller is that these classes can be made into generic components. The AddCategoryPage can be given a setup parameter and changed to a generic AddPage and then can be used with many different kinds of resources. The same with the AddCategory action. If a strict separation of concerns were not observed, this would be more difficult to acheive.

    I am finding that my applications define very few classes, but instead tend to build networks of object instances. The code is more complicated for a small example, but as your application grows, adding new functionality means mostly assembling pre-existing objects. I have been trying to move WACT more and more toward this model. (configurable components versus custom classes)

  19. #44
    SitePoint Evangelist
    Join Date
    Dec 2003
    Location
    Arizona
    Posts
    411
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Selkirk:

    Here is a good MVC link if you don't already have it:
    http://www.tonymarston.net/php-mysql...ontroller.html

    Thanks,

    JT

  20. #45
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Cool Link

  21. #46
    SitePoint Zealot
    Join Date
    Jun 2003
    Location
    Elsewhere
    Posts
    107
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by seratonin
    Here is a good MVC link if you don't already have it:
    http://www.tonymarston.net/php-mysql...ontroller.html
    Take a look at the attached image; it shows perfectly what I believe to be the common misconception about MVC and web applications.

    How many of you have ever sent a HTTP request to a server? Manually? How many read and interpret the resulting response? On a daily basis?

    Nobody does that, because it's the client software's job. Web applications don't contain presentation logic; they contain logic to create documents that can be interpreted by client software.

    Users don't send HTTP requests, client software does that. And HTML is NOT a user interface. A client application may interpret and render an HTML document into an interactive interface, but it's still just a document.

    Attached Images Attached Images

  22. #47
    Currently Occupied; Till Sunda Andrew-J2000's Avatar
    Join Date
    Aug 2001
    Location
    London
    Posts
    2,475
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Azmo
    Take a look at the attached image; it shows perfectly what I believe to be the common misconception about MVC and web applications.

    I went backwards, and actually, went back to HTTP and the payloads request/response. Why, the main misconception, I find is that many developers expect the payload of the request to be a standard document, now what about SOAP? Generally, it is in a standalone page, to handle the request, but with the emergence of XForms, I realized that this was not acceptable and therefore needed a controller, to handle the initial request, and content type.



    Also I find the XSL for the View poor…

  23. #48
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Azmo
    How many of you have ever sent a HTTP request to a server? Manually? How many read and interpret the resulting response? On a daily basis?

    Nobody does that, because it's the client software's job. Web applications don't contain presentation logic; they contain logic to create documents that can be interpreted by client software.

    Users don't send HTTP requests, client software does that. And HTML is NOT a user interface. A client application may interpret and render an HTML document into an interactive interface, but it's still just a document.
    And does PHP read the HTTP request directly? Whoops, need a web server in there. And what method did the client interact with the web server? Whoop, need TCP/IP in there. Are the client and the server on the same system? No...let see ethernet adapters and drivers...

    I think the point is that some abstractions are necessary. I believe one of the central points of this thread has been trying to establish the right level of abstractions the allow for the formulation of the correct vocabulary to express MVC concepts.

    Where I agree with you is that M V and C become very cloudy when you throw js into the mix. Where I do not agree is that you seem to just want to express the problem, but I don't see any movement toward trying to find a solution that is on topic for the thread...

    Perhaps I am misinterpreting what you have said?

  24. #49
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Perhaps I am misinterpreting what you have said?
    IMHO, Nope

    I get the feeling that Azmo doesn't care much about the MVC Pattern, and that's fair enough - it's not to everyone's taste etc.

    But if Azmo has a better solution, I'd be interested in hearing about it as well

  25. #50
    SitePoint Evangelist
    Join Date
    Dec 2003
    Location
    Arizona
    Posts
    411
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Azmo
    Take a look at the attached image; it shows perfectly what I believe to be the common misconception about MVC and web applications.

    How many of you have ever sent a HTTP request to a server? Manually? How many read and interpret the resulting response? On a daily basis?

    Nobody does that, because it's the client software's job. Web applications don't contain presentation logic; they contain logic to create documents that can be interpreted by client software.

    Users don't send HTTP requests, client software does that. And HTML is NOT a user interface. A client application may interpret and render an HTML document into an interactive interface, but it's still just a document.

    Azmo,

    I understand your point. However, I believe that the "User" is the client software or Web browser and therefore the picture is accurate. If we change the word "User" with "Web browser" and create another circle that interacts with that named "User", then maybe we would have something.

    JT


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
  •