SitePoint Sponsor

User Tag List

Page 3 of 6 FirstFirst 123456 LastLast
Results 51 to 75 of 142
  1. #51
    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 mwmitchell
    I'm sorry to ask such a dumb question in the middle of such a great topic, but what the heck is a portal? How does it relate to views?
    http://en.wikipedia.org/wiki/Portal

    Quote Originally Posted by definition
    A web portal is a web site that provides a starting point, a gateway, or portal, to other resources on the Internet or Intranet. The building blocks of portals are portlets. Portals typically provide personalization capabilities to their users.
    Views = Web Pages
    SubViews = "Blocks" or "Portlets"

    HTH

  2. #52
    SitePoint Guru
    Join Date
    May 2003
    Location
    virginia
    Posts
    988
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I was thinking more about the model that knows about validation and forms. What about MFV for Model Form and Validation? This has only to do with the model (when looking at MVC).

    If the model could simply have properties that define what each member is (firstname, char, min=1, max=10), you could have a Form class that could read the model (knowing it's interface) and then after the form was submitted, the Validation would be able to validate by looking at the model also. It would know that the firstname (for example) must be a string, and have atleast 1 character, but no more than 10. These 3 together would make up a nice group. A pattern? Get model, build form, validate.

    Any good?

    Matt

  3. #53
    SitePoint Zealot sleepeasy's Avatar
    Join Date
    Sep 2003
    Location
    Bristol, UK
    Posts
    145
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi, I'm - like all of you - trying to develop the Ideal Pattern for the Web as part of the framework I'm developing.

    I don't claim that my approach is revolutionary. You may have seen something similar - I don't know. I also fear it may not be that far from the MVC as I once thought it was. Not a bad thing in itself - it's just the "possibly wasted time" aspect. For now I'll just identify and briefly explain the main components of my approach. Maybe I'm going in the wrong direction, or maybe not. Feedback is what I want - good or bad.

    Pipe / ActionQueue
    This is a queue of actions. Actions are instantiated as they go into the pipe, processed while inside the pipe, and their data (if any) retrieved (by the response component) as they leave.

    Actions
    Actions are the Business Logic. Groups of actions make up whole Applications (forum, advertising, webmail etc.).

    There are two types of actions - Silent and Verbose. Silent actions just do processing, Verbose actions also produce data that has to be presented to the user.

    Actions can range from logging user clicks, to displaying a thread in a forum, to processing a form. A typical web page would consist of many actions.

    Actions can attach themselves to events.

    Persist
    For the persistence of objects - in a session or database, as serialized text or XML. Actions can be wholly persistent and/or may use other persistent objects.

    Events
    Events drive the system - they can occur at any time and from most components up until the last action in the pipe completes it's process() method.

    They are used to notify interested actions that a certain event has occured - usually corresponding with action objects succesfully completing their process() method although this is not a rule.

    Example
    One of the main events is the Event_NewRequestEvent. It occurs on each page request. The event carries some properties including the url of the page requested, etc. Actions can be configured to respond to Event_NewRequestEvent events that have a certain url.

    Example
    A Menu action is responsible for generating a menu. If the user is logged out the menu should have 'Log In' and 'Register' items. If the user is logged in: 'Log Out', 'Preferences', etc. The Menu action is instantiated and attaches itself to the UserLoggedIn_Event event. The Menu action completes its process() method, and has generated a menu for a logged out user. The next action logs the user's click. The next action is the processing and validation of a log in form (which succeeds). A User action (which is a silent action that has session state, and database persistence) is added to the pipe. The UserLoggedIn_Event is triggered. The Menu action receives notification of the event and modifies it's menu accordingly.

    Notifications
    When an event occurs any actions that have registered their interest in the event are notified.

    Action objects may or may not be instantiated at the time of an event. If they haven't been instantiated they are "Woken Up" (instantiated) and put in the pipe. Otherwise the action object is immediately notified of the event. In both cases the notified action object knows why it was notified and can react accordingly.

    Notifications also allow communication between the object that caused the event and the object receiving the notification (depending on the event).

    Response
    Data for presentation/transport is pulled from verbose action objects. "Templating" (with XSLT) and transportation is controlled by a set of classes suited to the different clients (Web Browser, SOAP Client, Terminal).



    The framework does have some other components but this post is already too long.

    I hope that was clear enough - I know I have a tendency to ramble on a bit.

    If you want some more details let me know.

    Off Topic:

    Great thread BTW, I've just got back from my Christmas break and was hoping there'd be a few good threads waiting for me when I got back. I wasn't dissapointed. This forum really is the place to be (as was mentioned earlier).
    Last edited by sleepeasy; Jan 7, 2004 at 05:06.
    Always open to question or ridicule

  4. #54
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    PHP Code:
    $page->addMvcBlock('login'); 
    $page->addMvcBlock('productList'); 
    Not bad Was thinking the same myself that something like this would be well smart... Want to share some more about how you implemented this with some script ?

  5. #55
    SitePoint Evangelist
    Join Date
    Jul 2001
    Location
    Michigan, USA
    Posts
    414
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Again, our Site Point Forum crew has abolutely amazed me. I've just done a quick read through and I feel as though I've barely skimmed the surface of what can be learned here. I wish I wouldn't have fallen behind here so that I could hav etaken it in chunk by chunk I'm sure I'll have some comments and questions once I read through the thread again, but go ahead and ignore them when they come around.

    sleepeasy - Would you be willing to provide some quick psuedo code about how some page (maybe a sample like the portal that was discussed earlier) would be built. Your method seems quite workable to me, but I'd need to see a more application based approach to grasp it.

    Also, someone had mentioned that a big problem with things is that people end up picking a pattern and trying to fit their problem to it rather than the other, and proper, way of coming up with a clear problem and then coming up with a pattern that is a workable solution. It's spot on and I noticed that I was doing it as well. OOOOO!! MVC! That sounds cool. How can I use it now if I want to make my website. It is a terrible way to do things, but what's a "newbie" to do

    I do believe that it is not completely worthless to do the above though. It does allow a beginner to learn a pattern, but more importantly it teaches people that knowing the problem is important in the first place. I never went through any sort of application design before I coded in the past. Now, after attempts at using MVC (and a few other patterns) both successfully and otherwise, I find myself sitting down and coming up with at least a set of requirements for my applications.

    Keep up the discussion!

  6. #56
    SitePoint Guru
    Join Date
    May 2003
    Location
    virginia
    Posts
    988
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    PHP Code:
    $page->addMvcBlock('login'); 
    $page->addMvcBlock('productList'); 
    Not bad Was thinking the same myself that something like this would be well smart... Want to share some more about how you implemented this with some script ?
    Yes I'd be very happy to. I need to comment some code and clean it up a bit. Then I'll put it as an attachment.

    Matt

  7. #57
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    That'd be great. Can't wait

  8. #58
    SitePoint Guru
    Join Date
    May 2003
    Location
    virginia
    Posts
    988
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    That'd be great. Can't wait
    OK, here it is:

    http://telegraphtomcat.com/SimpleMVC-example.zip

    It's nothing amazing, but to me, putting miny MVC's into other mini MVC's could be a a pattern? I guess that doesn't matter, what's important is that this is what made MVC work for me. In the examples there are no DB calls or whatever, just pretend that the data in the 'Actions' is coming from a db etc...

    Now, you'll see that this is a lot like Mojavi (using the same directory structure) but very simple, and it allows you to mix and match modules. A module is a group. a group consisting of an action, a view and anything else related (models and templates etc...)

    This isn't intended to show a framework, just the "idea" of binding MVC blocks together?

    Let me know what you think...

    Matt

  9. #59
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Okay, at the moment I'm having some real trouble with my Win98 installation, so I'm going to have to do a FORMAT C: /S and instead of Win98, I'll install WinXP Pro tonight

    So might be a wee while before I get back to you on my thoughts

  10. #60
    SitePoint Zealot sleepeasy's Avatar
    Join Date
    Sep 2003
    Location
    Bristol, UK
    Posts
    145
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Andy Tomaka
    sleepeasy - Would you be willing to provide some quick psuedo code about how some page (maybe a sample like the portal that was discussed earlier) would be built. Your method seems quite workable to me, but I'd need to see a more application based approach to grasp it.
    The most basic of pages could be built something like this.

    PHP Code:
    $eCentral Event_Central::instance();
    $eCentral->start();

    $pipe Pipe::instance();
    $pipe->add(new Menu());
    $pipe->add(new RSS_RemoteFeed("http://foo/bar/news.xml"));
    $pipe->add(new Login_Form());
    $pipe->add(new XML_Document("foo/bar/about.xml"));
    $pipe->add(new Advertise_Sponsors(Advertise_Sponsors::RANDOM));
    $pipe->start();

    $response = new Response(Client_Factory::getClient());

    while (
    $action $pipe->next()) {
        if (
    $action instanceof Action_Verbose) {
            
    $response->add($action);
        }
    }
    $response->send(); 
    Always open to question or ridicule

  11. #61
    SitePoint Guru
    Join Date
    May 2003
    Location
    virginia
    Posts
    988
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sleepeasy
    The most basic of pages could be built something like this.
    Wow, any chance you could explaing what's going on, and maybe a little source code?

    Looks very interesting to say the least,

    Mat

  12. #62
    SitePoint Zealot sleepeasy's Avatar
    Join Date
    Sep 2003
    Location
    Bristol, UK
    Posts
    145
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by mwmitchell
    Wow, any chance you could explaing what's going on, and maybe a little source code?

    Looks very interesting to say the least,

    Mat
    I'll explain how it works but I can't show you much source code because I've just started to change a few things so it's all a bit of a mess.

    Event_Central (Singleton) is the class that notifies actions when events they're interested in occur. We have to start() this before any actions are processed.

    PHP Code:
    $eCentral Event_Central::instance(); 
    $eCentral->start(); 
    Next we add some actions to the Pipe (Singleton), and start them.

    PHP Code:
    $pipe Pipe::instance(); 
    $pipe->add(new Menu()); 
    $pipe->add(new RSS_RemoteFeed("http://foo/bar/news.xml")); 
    $pipe->add(new Login_Form()); 
    $pipe->add(new XML_Document("foo/bar/about.xml")); 
    $pipe->add(new Advertise_Sponsors(Advertise_Sponsors::RANDOM)); 
    $pipe->start(); 
    Next all action objects (each will have finished their main process() method) are passed to the Response object.

    The Response object retrieves the applications data from each action object. This data is a DomDocument (XML) object (or a subclass). All the DomDocument objects are joined to form an XML document ready for transformation.

    In my previous post I mentioned that actions are part of an application. Every application has it's own settings (stored in XML or database table). When an action is added to the pipe the settings for the application it belongs to are retrieved by it's superclass.

    It uses the object passed to it to find out what content type it will need to send (and to check that the application has a template to transform it's data into that content type). In this case Client_Factory::getClient() is used to detect the client and return a suitable object.

    Each action object's settings are also retrieved by the response object. This is where the response object gets the names of the templates to use for each action.

    (This next bit isn't quite finished yet)

    A check is also made for whether the action requires a different object to transport the response. For example, an action "foo" may be setup to have it's data transformed and displayed in the default way, but (due to a user selecting an "Email it" checbox) may need it's data transformed into HTML but need it be sent via email. In this case the Response object would create a new Client_Email object to use to transport "foo"'s data.

    PHP Code:
    $response = new Response(Client_Factory::getClient());

    while (
    $action $pipe->next()) { 
        if (
    $action instanceof Action_Verbose) { 
            
    $response->add($action); 
        } 

    And finally, the page is displayed. The way send() will work will be different depending on the object passed to Response(). But for a web browser it just echo()'s the XSLT transformation.

    PHP Code:
    $response->send(); 

    I hope I explained it well enough. I should've been in bed a long time ago

    Any questions/ comments?

  13. #63
    SitePoint Evangelist ghurtado's Avatar
    Join Date
    Sep 2003
    Location
    Wixom, Michigan
    Posts
    591
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Sounds like a very clean approach, I really like it. Very thin controller pages is definetly a good goal these days to me.

  14. #64
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Been away for a while on a new year trip after starting off this discussion (a happy new year to you all ).

    Thanks to everyone who chipped in. Lots of fascinating comments which will take some time to digest.

  15. #65
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    MVC causes a lot of confusion. I think I've also been confused at times. The key is, I think, that MVC is great for printing a page BUT an http request to a dynamic website has a lot more going on than merely printing a page - at times that might merely be a side issue to the main meal.

    I think a common mistake (which I've also been guilty of) is to try to fit the entire process inside MVC. However, it's maybe better to view MVC as just one part of a three-stage process that may also include pre-output tasks and post-output tasks. Interpreting the request might be another stage.

    Sandwiched in between, I'd see a layer with responsibility for selecting dynamic & static content, formatting it, and finally printing it. Anywhere some data needs to be defined and sent to client/written to file etc is perhaps the place to apply the MVC pattern - and nothing else.

    Some details of a front controller along these lines in this thread http://www.sitepoint.com/forums/showthread.php?t=148280.
    Last edited by McGruff; Jan 22, 2004 at 06:20.

  16. #66
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    ...may also include pre-output tasks and post-output tasks.
    Pre output tasks I can grasp, though post output tasks ? I do not understand this point, where once the server sends the page, that's it.

    A scripting langauge can not have anything more to do with that page, true ?

    Maybe you can give some examples of what you mean by post output tasking please ?

  17. #67
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Pre- and post-output tasks are very well handled using the InterceptingFilter pattern. See http://java.sun.com/blueprints/corej...ingFilter.html. Although this pattern does not strictly belong in MVC, it is a piece of the puzzle of how the problems with 'just MVC' can be solved.

    Sandwiched in between, I'd see a layer with responsibility for selecting dynamic & static content, formatting it, and finally printing it.
    MVC is a very course-grained pattern of course. Although it speaks of only three objects (Model, View and Controller), each one of those objects can contain of a virtually unlimited number of other objects and even layers within layers. It is very well possible to create your own layers within the Controller, like you describe.

  18. #68
    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 Widow Maker
    Pre output tasks I can grasp, though post output tasks ? I do not understand this point, where once the server sends the page, that's it.

    A scripting langauge can not have anything more to do with that page, true ?

    Maybe you can give some examples of what you mean by post output tasking please ?
    Sending an email, logging page views to a db, capturing a buffer and writing to file.. anything really - and I guess as much as you can possibly push in there to gain whole hundredths of a second on page load times...

    The script, as you point out, has to come to an end sometime but state can be maintained with sessions.

  19. #69
    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 Captain Proton
    MVC is a very course-grained pattern of course. Although it speaks of only three objects (Model, View and Controller), each one of those objects can contain of a virtually unlimited number of other objects and even layers within layers. It is very well possible to create your own layers within the Controller, like you describe.
    Is it better to embed MVC in apps not whole apps in MVC?

    A single http request might spawn several "print something" requests (eg email, write a log file, & of course the page sent to the client). Each one should possibly have its own MVC-based sub-routine with each controller responsible for its own model and view and nothing else.

  20. #70
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think so. MVC is in a way embedded in applications, I guess. But you have to design your application in such a way that this embedding is possible.

    The Model is the key to this. You have to design the model of your application in such a way that it is completely independent of the presentation layer. Doing this right the first time may be hard if not impossible.

    The Model of an application should be coded in such a way that it can be used by any type of presentation layer: command line, XML-RPC, HTML, WAP. I think it helps if you think of the model as being a completely separate tier of the application, which might even be on a different server. If your app is structured in a way that this is conceptually possible, then you have coded a good model

    When you are in doubt of whether a certain piece of code belongs in the model of an application or in the presentation layer (= Controller + View), think of the above.

    When an application model exists, the VC of MVC is a way to structure (part of?) the presentation layer of the application.

    In conclusion, MVC is part of an application, it's definitely not that an application consists of only M's, V's and C's.

    In the discussions on this forum, people (including me) also often mention thinks like FrontController and InterceptingFilters. The way I see it, these design patterns are not part of MVC, they merely complement it.

  21. #71
    SitePoint Enthusiast
    Join Date
    Mar 2002
    Posts
    27
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Widow Maker
    Pre output tasks I can grasp, though post output tasks ? I do not understand this point, where once the server sends the page, that's it.

    A scripting langauge can not have anything more to do with that page, true ?

    Maybe you can give some examples of what you mean by post output tasking please ?
    An output filter works on "suppressed" output. That means to say that you can Save output Content until the absolute end of the request. A better way to think of this scenario would be an email template system. I say this because when folks think of Http Requests and Responses, they automatically see it as a one way street... it is and it isn't.

    Imagine creating a text file that will serve as a template for an email message. You put in place holders that should be replaced before the message is sent such as email address (from and to), subject, body, and maybe even some other headers.

    1. You query a database for all the data you need
    2. You pull in the contents of the external text file containing the email template text
    *3. You run your "OUTPUT FILTER" upon the contents of the text file
    4. You send this output to your send email routine (function, static method, etc)
    5. Now you will probably have browser output here letting the user know if the message was sent successfully or not.
    6. Even this output could have been "saved" until the end and place holders replaced

    Another way of thinking of Post Output is logging.
    After all the above steps, you may need to log to a file or database what just happened.

    Think about caching... Say we wanted the email output to be cached so that the next time this sequence is run there is no database query run, there is no file parsing, and there is no variable substitution. This could easily make the app 400% faster.

    This would all have to happen at the end of the request.

    Hope this helps.
    Wil Moore III, MCP | Integrations Specialist | Senior Consultant
    DigitallySmooth | HotBusinessDirectory

  22. #72
    SitePoint Enthusiast
    Join Date
    Mar 2002
    Posts
    27
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by laidbak
    An output filter works on "suppressed" output.
    BTW, the best way to do this in php is http://us4.php.net/manual/en/ref.outcontrol.php
    Wil Moore III, MCP | Integrations Specialist | Senior Consultant
    DigitallySmooth | HotBusinessDirectory

  23. #73
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks, it does make things a lot clearer

  24. #74
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    This is an amazing thread. Better late than never.

    Quote Originally Posted by lastcraft
    In three years of tackling these issues I have not once managed to understand how MVC applies to the web.
    I think the term MVC is wrecked. Perhaps it no longer has any definite meaning.

    Quote Originally Posted by lastcraft
    The "web application" is an illusion created by a sequence of scripts. To maintain that illusion we have to have some kind of super controller to manage the steps. This step controller doesn't usually exist in any single script. Because in PHP we are always completing the last action and offering up the next, we are actually doing two half jobs. This means that the real application control, the real top level meat, occours half way between each script. A good way of exposing it is to split all top level scripts into *_display.php and *_handler.php in a typical application. You suddenly find that you need a bit of extra logic either at the end of the handler script, or the start of the display script to select the next display. Hardly surprising that this very important top level logic gets buried away and becomes difficult to modify. I wouldn't call the class that deals with this logic a "controller". More of a "navigator".
    I think you are on to something with this idea of "two half jobs." Imagine an alien software anthropologist studying 20 applications written to use 20 different so-called MVC frameworks. Surely, he would not come away with the idea that the central abstractions of the application were models, views, and input controllers. He would come away thinking the central abstractions were commands or actions (*_handler.php) and views (*_display.php).

    Quote Originally Posted by Azmo
    To be honest, I find it a bit surprising that so many people on these forums are still trying to use MVC, when the pattern raises so many questions about application structure and layering, the placement of concerns, etc. Just look at all the threads about the location of SQL queries, form validation, etcetera. And as far as I can tell, most (if not all) of these problems still have to be solved by the people who originally submitted them, so it doesn't look like the MVC pattern is really solving any problems...
    Depressing, isn't it. There seems to be no consensus on the issue. As you say in a later comment, people seem to be pursuing MVC for the sake of MVC:

    Quote Originally Posted by Azmo
    I think the problem originates from the type of question people asked themselves when they started implementing MVC in web applications: they asked "how can I solve this problem using MVC?" instead of "what is the best solution for this problem?" or even "what exactly is the problem I'm trying to solve?". Quite a number of people seem to have created a sort of mental link between web apps and MVC; you have to use MVC for your web app if you want to separate business logic from presentation. You're not allowed to stray from the MVC ideology, because MVC is the only 'right' solution.
    Quote Originally Posted by ghurtado
    While our framework at work is far from a "true" MVC model, I have found that many of the principles that I learned through MVC do apply very well on the web. Most notable of which is probably to separate a view, and more specificially, a "TemplateView" kinda layer. For us, following MVC as a loose guideline (more than as a Bible) has been helpful in more than one ocasion. I still like the principle of a "controller" page as your main entry point and switchboard.
    An alien web software anthropologist would almost have to add TemplateView and FrontController to the list of successful web development patterns. These are tried and true.

    Quote Originally Posted by lastcraft
    I have no trouble separating the view from the model. All you have to do is to try to imagine a web version, web services version and command line version. Anything common to all ends up in the model and so a refactoring we go. This pattern used to have a name too - Document/View. This was the pattern adopted for Windows apps. because the old Smalltalk controller functionality, mouse clicks and the like, was now handled by the Windows OS itself. The old controller had very little purpose.

    It's the controller that is the problem.
    I would like to think that our alien anthropologist would find a segregated model in each of the applications he examined. But I am not so sure.

    Its hard to imagine making such huge changes in the UI of your application without having to change both view and controller together. Its Mvc with vc being the UI. I think thats why we have Document/View. The benefits of separating the input and output sections of the program just aren't clear and aren't easy. There is definitely a relationship between the input and output, but perhaps sometimes there can be too much of a relationship?

    So is there no benefit for separating input and output in a PHP web application? I think there is some benefit, but I am still developing this idea.

    Signs your application mingles input and output code too much:
    • It would be hard to move it to different url?
    • If POST were deprecated, I would have to change alot of code.


    My list needs work.

    Quote Originally Posted by brainpipe
    An almost compete lack of understanding of when and why to use a Front Controller (which I think most developers seem to think is the whole of MVC). There's almost no need for it (imo) in smaller web applications, because you can do an effective job of separation without it, and FC always complicates the code. In smaller web apps, the Page Controller does the trick nicely.
    Every program grows until it implements a front controller or is replaced by one that does?

    Quote Originally Posted by mwmitchell
    be interested in seeing how you 'bind' the output of multiple 'MVC' results, to one object. I mean if you have a command that handles a login, a command that handles a search, and a command that handles a message form, all on the same page.... What do you do to bind them all together, to the same view, without all of them knowing about the existence of the other. This is where I stumble.
    Controlling the outcomes for a single page is the job of a Page controller. Its the job of the page controller to determine if the request for that page should trigger a login, search, command, etc.

    I've noticed that every Front Controller/MVC framework has a cinderella page controller pattern hidden inside somewhere. The Front Controller takes the credit and they won't let the page controller out in the daylight or even give it a proper name, and mostly doesn't even realize how important it is. But, the page controller there, toiling away. Its time to give cinderella her glass slipper back and sharpen the page controller abstraction that is inside every front controller.

    I had this epiphany about page controllers when I was acting as an alien software anthropologist and studying struts. I noticed that struts had an ActionMappings object in between the front controller in the framework and the action that the framework user wrote. I noticed that it performed the exact same functions as the FormController page controller in WACT.

    So, then I started looking at other Java & PHP frameworks. They too had similiar objects. I found in the ones that didn't, the users ended up writing page controller code in their action. None of the frameworks called their objects page controllers. Many of them blurred the responsibilities between the action, page controller, front controller, application controller, intercepting filters, and commands.

    Fowler talks about a Front Controller dispatching to commands. Core J2EE patterns talks about Front Controllers being responsible for managing commands and managing views. I no longer think of it this way. I think the front controller's job is to dispatch to a page controller. Its the page controllers job to manage views.

    Look for wherever component(s) decides if a form should be redisplayed because of invalid input, that is where you find the page controller in that application.

    Just because an application has a front controller, doesn't mean that it doesn't have pages.

    I think there is something to be gained by embracing the inner page controller. This philosophy is reflected in the current WACT controller design.

    Add page controller to the tried and true web application patterns catalog.

    Quote Originally Posted by ZangBunny
    Quote Originally Posted by lastcraft
    The template may dictate (with custom tags) the domain code that gets executed and so may be more than just a view. Templating is mostly orthogonal.
    It could, but then it wouldn't belong in an MVC architecture. In a clean MVC only the controller can nudge domain code into execution. It then collects the domain objects that result from the logic and hands them off to the view for display. The view should strictly speaking do nothing more than use getters on the domain objects and put their data into the right template variables (if you use one).
    Actually, as long as the domain code that gets executed doesn't change the model, but merely reads the model, I think that its still MVC safe. If there is one long term goal that I hope that WACT can acheive, its moving the language of template markup out of the programming realm and into the domain realm.

    Quote Originally Posted by lastcraft
    The real difference though is that the controllers in a GUI app. both present the button and hand off the results of the click.
    I think that this is the case in DocumentView. I think the point of smalltalk MVC was that the view would present the button and the controller would be responsible for the click. (Controllers would query the view as part of finding out where the cursor was located.) Also, there was a hierarchy of controllers and a heirarchy of views. Applications Programming in Smalltalk-80(TM):
    How to use Model-View-Controller (MVC)


    One aspect of the the GUI MVC pattern is that it seems to emphasize multiple simultaneous views and instant updates of each view when the model is changed. This doesn't seem like it would matter in a web environment.

    Quote Originally Posted by Captain Proton
    I think that a lot of people haven't "found the need" to use MVC, but they just want to use it because it is indeed a buzzword (at least on these forums ). For me, the need ... arose from having to support multiple presentation layers to one of my applications. My previous apps contained mixed model, view and controller code that made it hard to support another web interface (like WAP) to it.

    Also, I think that MVC is part of a "bigger whole", something that I've seen called "separation of concerns" or "SoC". That is after all what MVC is about! putting code with different responsibilities that should not be mixed into different classes (layers if you will), to create more flexible and reusable code designs. But MVC is not where SoC stops, you can apply it to your entire application. I even believe that SoC is something like a 'natural cause of evolution' of object oriented programming.
    I think you are spot on with this. until we feel the need for a specific separation of concerns, we won't understand it. There are others: segregating HTML from code (templates), natural language from code (i18n), SQL from code (DAO), etc.

    I think this helps explain the variance on this issue. People have different needs for separations, and they all tend to call theirs MVC.

    I'm still trying to understand the idea of separating input and output in a web application. I do it in my programs. Not with iron discipline all the time, but I do try. I do think that its a good thing. I just can't explain which problem it solves. Perhaps I should re-think this habit?

    Quote Originally Posted by lastcraft
    The template contains control information. It does this every time you add an anchor tag. You need to generate all such links to be strict MVC. This is overkill even when using front controller style links unless you somehow build it into your template engine. Except that if you build it into your template engine you are breaking MVC again. Seems you cannot win.
    I've been struggling with this idea in WACT. Do the templates contain control information? I think there is a difference between control information (sounds like you mean navigation information) and a controller.

    I am not sure that building a capability into the template for this would break MVC. If the controller places the information in the model and the template just reads it out, what harm?

    BTW, struts has a tag library to generate anchor tags based on querying the front controller. WACT will soon have similar capability.

    Quote Originally Posted by lastcraft
    If you use smart widgets (e.g. JavaScript generators) with complex selections then the only way to interpret data is via. those widgets. This means all interactions must go through the views.
    I've been trying very hard in WACT to prevent these interactions from going through the view. Its an optimization issue. Imagine submitting a form as a three stage process: Initial presentation, validation review, and process result. When the valid form gets POSTed back to the server in the last phase, it is likely that the view that contained the form that produced the input data will not be the next form you want to display. (perhaps a thank you page instead.) So why should we create the view that contains the form and its components when we aren't sure we are going to display it? This would violate the principle of "half jobs" that you described at the beginning of this thread.

    Therefore, we define the action and data handling for the form seperately in the page controller/action portion of the application. Note that JSF and .NET define this part as an event on the component, which is a DocumentView approach. But then, being stateful, they already had the view loaded in the server when the request came in, so they don't care about the cost of building it up again.

    So here is some code which registers an action that will occur when a button is pressed on a form:
    PHP Code:
    $Page->registerAction('ConvertToLower', array('lower')); 
    ConvertToLower is the name of the class which will handle the action. The action is not invoked unless a value for lower has been passed as input to the page. lower is the name of the post variable from the template (view) :
    Code:
    <input name="lower" type="submit" id="lower" value="Convert To lower Case">
    They are related, but loosely coupled only by the name which they share.


    Quote Originally Posted by lastcraft
    It doesn't seem to explain how things are going to scale. You have to create a controller pretty much for each view.
    I am finding with the current WACT implementation that I am instantiating a semi-generic controller:

    PHP Code:
    $Page =& new EditPage('category');
    $Page->run(); 
    EditPage is a re-usable Page Controller. 'category' is the thing getting edited. The EditPage uses this to load the correct model object and correct view based on a naming convention. It will also dispatch to the correct action based on a naming convention. The View is also generic and parameterized. it takes a template name. The template itself is highly modular, wrapping a custom defined form with components inside a standard 'edit form' layout. I am finding that for stupid CRUD applications, even the action and the model that get loaded might also end up being generic classes configured with a parameter. This is a very dynamic setup and I am not sure if its a good thing, but I will say one thing. There is very very little duplicate code.

    Quote Originally Posted by lastcraft
    In the OO world you are likely to have multiple domain objects, each with viewlets say, so that you can rearrange the content flexibly. Does each subview have it's own controller? If you do then in MVC you will have to build your C tree as well as your V tree . I think MVC is anti-OO here. It requires a god controller indeed if it is going to assemble all of the views and read all of the input data, rather than let them build their own children. This is an unlikely case (I have never needed it), but one that is easily dealt with by custom tags.
    Working on this issue is challenge for the near future. I've run into the issue of needing viewlets and subviews. I've programmed some support for the CompositeView pattern, but have not yet determined what impact this will have on the controller structure.

    Quote Originally Posted by sweatje
    So, if I want to say add a field to be processed, I will need to:
    a) modify the Model to accept for update the new field
    b) modify the View to add a new field to the form
    c) modify the Controller to know to extract the request var and pass it to the Model::Update()

    What have I then gained? Not necessarily a separation of concern (as we just witnessed, it touched all three components) but what I have gained is a definite structure to my application.
    Smells like shotgun surgery. I'm seeing the same thing using the WACT FormPage. Item c is automated in the framework in WACT, but its still shotgun surgery. What is the alternative though? It seems like even the DocumentView model of .net separates the definition of the field from the processing of it.

    Quote Originally Posted by lastcraft
    Now something a bit more radical perhaps.

    Thinking about Jason's problem with the constantly changing model, how about if we could create the core business objects like this...

    ...

    This is not my idea, it is the "Naked Objects" way of looking at the world. A viewpoint that is very interesting.
    Naked Objects works for simple CRUD, but for complicated user interactions, you will either have to complicate your model to make the UI simple, or complicate the UI (for the users) to make the model simple.

    My previous EditPage example is very close to a naked objects approach. I think it will break when the pages get complicated. Fortunately, there are always a few simple pages laying around in any application of sufficient size.

    Quote Originally Posted by Captain Proton
    I can't really remember how much of the MVC-pattern I 'discovered' myself and how much of it I implemented after reading about it, but I do know that I haven't just applied it to my code without thinking about what problems it would solve.
    I think the mark of a good pattern is that it keeps getting independently re-invented.

    Quote Originally Posted by Captain Proton
    A good example of this is perhaps the front page of PHPNuke. ... Think of a page that displays a news item. Because you don't want the View to access the data source directly, the controller for that page would load the news item from the data source and pass it on to the View. ... Where would you put the code to load such data?
    I do not think loading this information in the view itself violates MVC in any way. The view doesn't need the controllers help to go fetch some data from the model and display it to the user. The only place the controller would come into the picture is if the information in the subview was dependent on the user's input for that request. The view has free access to the model.


    Well, to sum this thing up, lets go back to our alien anthropologists list of tried and true patterns for web application development:

    Front Controller
    Page Controller (optional application controller)
    Command
    Model
    View
    Template

    So what is web MVC? Well, what ever GUI MVC was, this is what I think web MVC means post struts.

  25. #75
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Well, to sum this thing up, lets go back to our alien anthropologists list of tried and true patterns for web application development:

    Front Controller
    Page Controller (optional application controller)
    Command
    Model
    View
    Template

    So what is web MVC? Well, what ever GUI MVC was, this is what I think web MVC means post struts.
    Great - that looks like progress.


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
  •