SitePoint Sponsor

User Tag List

Page 2 of 2 FirstFirst 12
Results 26 to 37 of 37
  1. #26
    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 auricle
    As one using Phrame, you surely aren't too concerned about round trips to the server!
    I have actually gone on record regarding the utility of this:
    http://sourceforge.net/mailarchive/m...msg_id=2908543

    Quote Originally Posted by Jason
    -- Arnold Cano <arnoldcano@ya...> wrote:
    > 3. The current design is not as efficient as it could
    > be because every request into the controller results
    > in an additional request via HTTP redirect via a call
    > to the PHP header() method (thanks Ross Keatinge). I
    > modified a local copy of Phrame to output the view
    > directly as part of the original HTTP request. This
    > change resulted in a new ActionView class that
    > contained a display() method. From an Action's
    > perform() method I would return an ActionView object
    > to the ActionController. Then in the index.php file I
    > would get a reference to the ActionView object from
    > the ActionController and call it's display() method.
    > This change shouldn't affect Phrame's ability to use
    > various display technologies such as Smarty, XSLT,
    > Flash, etc.

    I disagree with the idea of removing the redirection from the architecture
    because it serves a very useful purpose, one that, IMHO, far outweighs any
    performance considerations.

    The redirection after a POST request forces the user's browser to issue a GET
    request for the view page. This has the effect of correcting a major problem
    with users hitting the refresh button on the next page, forcing the browser to
    re-submit the POST request. Most users are just hitting refresh to make sure
    they are seeing the latest data on the view page, and are confused when the
    browser asks them if they want to re-post the information. Most consider this
    an application error rather than a user error Redirection happily takes care
    of this situation, the user hitting refresh will submit a GET request for the
    view page as they most likely intended in the first place.

    Performance wise, it is not as if you are fetching and rendering the whole page
    twice, the header is a single packet traveling to the browser asking it to
    issue a GET request. There is one additional round trip between the server and
    the browser for this, but it should not be a significant enough problem to
    eliminate the benefit of redirection described above.

  2. #27
    SitePoint Enthusiast Remy's Avatar
    Join Date
    Oct 2002
    Location
    Amsterdam
    Posts
    47
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote: Jason

    -- Arnold Cano <arnoldcano@ya...> wrote:
    > 3. The current design is not as efficient as it could
    ...<CUT>...
    the browser for this, but it should not be a significant enough problem to
    eliminate the benefit of redirection described above.
    Fowler also describes this redirect to a view for MCV: The controller handles the request and performs the needed action on the model(s). Then the controller adds the needed data to the HttpRequest and redirect (with a new request to the webserver) the request to a view.

    I am still thinking about if this is usefull. The point described above is at least one benefit, but a second request will cost some performance.

    Another benefit is that it forces you to seperate the view from the rest. A templateObject (even if it uses PHP) is not needed. The view just gets the needed data from the request.

    And what bothers me, is that Fowler changes the HttpRequest. I don't think that the HttpRequest should be changed (it should be read-only IMHO). On the other side, where should it be altered: a HttpResonse object?.

    I'm very interested on toughts from others about this...

    -Rémy

  3. #28
    SitePoint Addict
    Join Date
    Aug 2002
    Location
    Ottawa, Ontario, Canada
    Posts
    214
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I don't use an MVC approach here at work (I use the Fusebox framework), but just to comment on the benefit of a redirect after a POST:

    I really think the benefit of a second request as a result of a redirect far outweighs the potential price of not doing it. When I code multi-page calculators that we use at work (a wizard-like interface for most of them), I always have all the forms submit to a special "page" (fuseaction in Fusebox terms) that calls all the validation code, and then determines what the next appropriate page in the wizard should be (i.e. next page, skip a page, go back to the posted page because of errors, etc), and then it redirects to the appropriate page. This saves quite a few headaches with people hitting the refresh button and re-submitting data accidently.

    I guess if you have a slow server (relative to your volume) it could be an issue, but for me it certainly is a great benefit.

    Cheers,
    Keith.

  4. #29
    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 Taoism
    I guess if you have a slow server (relative to your volume) it could be an issue, but for me it certainly is a great benefit.
    I think the main concern in this case would be latency. If it just takes too long for a packet to make the round trip, then asking the client to ask for a new page is the wrong architecture. i.e. if your web server were on Mars, this would not be a good design becuase if you are going to go to the effort of sending information, you might as well send a page instead of a packet telling the user to request a page.

    In my environment I typically develop intranet application, meaning communications it taking place at 100Mb. This being the case, latency is not a factor in my decision making regarding applicaiton architecture and the benefits of asking the client to reqest another page do far outweigh the additional server round trip.

    Regards,

    Jason
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  5. #30
    SitePoint Zealot
    Join Date
    Feb 2003
    Location
    Virginia
    Posts
    143
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    In my environment I typically develop intranet application, meaning communications it taking place at 100Mb. This being the case, latency is not a factor in my decision making regarding applicaiton architecture and the benefits of asking the client to reqest another page do far outweigh the additional server round trip.
    Exactly.. Each case is unique and one simple formulas of MVC will not solve all problems or scenarios.

    How much longer are we going to harp this MVC thing it's starting to feel like the flu.

    I suggest we use what WORKS. Then attempt to break down the parts into workable patterns, MVC or not.

    Res

  6. #31
    SitePoint Evangelist ghurtado's Avatar
    Join Date
    Sep 2003
    Location
    Wixom, Michigan
    Posts
    591
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    How much longer are we going to harp this MVC thing it's starting to feel like the flu.
    We should harp it until everyone who has something interesting to say about the matter has shared their opinion with everyone else (good, valuable points keep coming up in the discussion), for the sake of reaching the ultimate web application architecture. This may very well never happen, but to aim for this goal is what keeps good creative ideas happening.

  7. #32
    SitePoint Zealot
    Join Date
    Feb 2003
    Location
    Virginia
    Posts
    143
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    ...until everyone who has something interesting to say about the matter has shared their opinion with everyone else (good, valuable points keep coming up in the discussion)...
    Granted, which is why I folowed up with.

    I suggest we use what WORKS. Then attempt to break down the parts into workable patterns, MVC or not.
    Thanks
    Res

  8. #33
    SitePoint Evangelist ghurtado's Avatar
    Join Date
    Sep 2003
    Location
    Wixom, Michigan
    Posts
    591
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I suggest we use what WORKS.
    Maybe I am being a little thick-headed, but how do we determine what works? I suppose at the basic level you could say that all the frameworks that are being discussed "work", if by that you mean that with them you can get your project finished and running. But from there we also have things like ease of use, learning curve, ease of understanding of the code used in these frameworks, ease of debugging, extensibility, layer separation, robustness, flexibility, standards compliance, customizability (sp?), and a miriad other issues that are really what separate the good from the best. I know it has been asked a million times before, but does anyone venture come up with a framework comparison chart?

  9. #34
    SitePoint Zealot
    Join Date
    Feb 2003
    Location
    Virginia
    Posts
    143
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ghurtado
    Maybe I am being a little thick-headed, but how do we determine what works?
    Good question. One of the first things I noticed about the MVC conversation is that it turned into the "tower of babble" the more in depth the discussion ran. People had to start defining multiple words while other people ,like myself, had to ask what was meant by various terms and phrases.

    It got confusing because although we are intelligent people we are not in exact agreement of what language is best for any given pattern, process, design element/phase - whathavehyou.

    Realizing my own ignorance, I went searching for a way to better communicate and exchange ideas with others. In doing so I found a great book called "The Object Primer". I actually got it by mistake and nearly returned it because it starts somewhat slow and it seems amateurish at first. Quickly though, I realized how in depth this book ran - for instance, it goes through every level of the development process from a team perspective while repeating language and ideas in ever greater depth. Things like CRC modeling, Sequence diagrams, Conceptual class modeling, Activity diagrams, State diagrams, Collaboration modeling, Component modeling, Prototyping, and the multitude of Analysis, Design and documentation ideas and techniques he gave it really is a solid read.

    Anyhow, I'm attempting to tighten my language and so I'm on my 2nd read of the book and looking for other books that expound on the ideas I have learned here. I still need to take a look at Harry's book, being he writes so clear - that's an unusual talent.


    Oh yea, in case you're still reading.. past step one, step two is to define the problem by modeling the requirments and their relationship to one another - in other words the Domain model.


    toowordy?
    Res.

  10. #35
    SitePoint Zealot
    Join Date
    Jun 2003
    Location
    Elsewhere
    Posts
    107
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sweatje
    I think the main concern in this case would be latency. If it just takes too long for a packet to make the round trip, then asking the client to ask for a new page is the wrong architecture. i.e. if your web server were on Mars, this would not be a good design becuase if you are going to go to the effort of sending information, you might as well send a page instead of a packet telling the user to request a page.
    If latency is a problem, it will be a problem for all requests a client makes. Most of them will be GET requests, so the occasional additional redirection after a POST request won't have much of an impact on the quality of the service.

    Personally, I think redirecting after each POST request is the only right solution, unless you're working on an application that has no direct user interaction. The additional request, traffic, and latency are not nearly as annoying as having to delete double posts, or not being able to refresh the resulting page...

  11. #36
    SitePoint Zealot
    Join Date
    Jun 2003
    Location
    Elsewhere
    Posts
    107
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ghurtado
    Maybe I am being a little thick-headed, but how do we determine what works?
    I think it's safe to say that any vocabulary sufficiently describes the problem domain, when people no longer feel a need to make up their own terms to describe what they mean. Of course, as the problem domain is analyzed further, the vocabulary may need to be changed. This is one of my objections to MVC: because it has become some sort of Holy Grail for developers, there's no real room to evolve our language.

    Quote Originally Posted by Resolution
    One of the first things I noticed about the MVC conversation is that it turned into the "tower of babble" the more in depth the discussion ran. People had to start defining multiple words while other people ,like myself, had to ask what was meant by various terms and phrases.

    It got confusing because although we are intelligent people we are not in exact agreement of what language is best for any given pattern, process, design element/phase - whathavehyou.

    ... step two is to define the problem by modeling the requirments and their relationship to one another - in other words the Domain model.
    Right now I'm working on a post which may (should) help to describe the problem domain better than MVC does. I'm also trying to motivate my objections to MVC as a description of the problem domain, but it's all taking quite a bit of time...

  12. #37
    SitePoint Evangelist ghurtado's Avatar
    Join Date
    Sep 2003
    Location
    Wixom, Michigan
    Posts
    591
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Res,
    There isnt such a thing as "too wordy" on these forums, you know that by now

    At any rate, I suppose that I'm going back to square one, to define the "problem" we are trying to solve. Its not easy, so I'll give it my best shot.

    1. First, we are trying to come up with a high level design approach, a combination of best practices and patterns that fits the development of web application development, and if neccesary, the one of PHP web application development. These is already hard in itself since the only point of reference most of us have (as far as popular patterns go) is MVC, and to be honest, it accomplishes many of the goals that we set for it in web development (perhaps because it has "elastic" properties that allow us to use the pattern to fit almost any problem domain).

    2. Once a reasonable amount of input or information is discussed, and if we ever define a new top level "pattern" for web applications, I suppose the natural progression would be to develop a "framework", or the materialization of these ideas and practices, as the embodiment of what has been decided upon. This might just be to take and apply to existing frameworks, or even create one of (your/our) own. I'm not too concerned about this part, because everyone seems to have a "plan" for their ideal framework in these forums and its possible that at that point each one of us will split up and "get to work" to apply what we learned in creating our own framework, or to demonstrate it all to be garbage. At the present time in web development and specially at this time in PHP, I think the multiplicity of approaches and the number of frameworks out there, both mature and in development, is actually a very good thing, since very soon we will start to see the leaders rise up.

    I have to confess I also have bits and pieces of a framework in mind, and I will likely develop my own as well, the worst that will happen (the most likely thing that will happen) is that it will be deficient in many areas, and the learning of what not to do and why will prove invaluable as it always does


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
  •