SitePoint Sponsor

User Tag List

Page 3 of 3 FirstFirst 123
Results 51 to 65 of 65

Thread: RFC on MVC

  1. #51
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Two words: User Agent.

  2. #52
    SitePoint Zealot
    Join Date
    Jun 2003
    Location
    Elsewhere
    Posts
    107
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    First of all, I'd like to apologize to Selkirk for derailing his topic, and turning a topic about one of the better MVC articles into a whinefest.

    Since I feel I can't leave these last few replies unanswered for courtesy's sake, I'll respond as briefly as I can.

    The problem I have is mostly linguistic I think (it's taken me some time to realize this). IMO class names should give a good indication of the behavior and responsibilities of their objects. I don't think the terms 'Model', 'View' and 'Controller' fit this criterium; they're not intuitive.

    Secondly, I prefer to find a clear language or vocabulary for each of the domains I'm working with: the business domain (application as it's perceived by the user), the physical domain (servers, network ), the web domain ( client software, webbrowser, webserver ), and the application domain (all concerns, aspects and elements of the web application). Having a rich vocabulary makes it easier to understand the problems and the environment we're dealing with. (This sounds rather pompous IMO, but I can't find a better way to say it.)

    And finally, I believe the MVC pattern is being used to solve the problem of web applications. But as far as I understand things, patterns are supposed to emerge naturally after the problem has been solved a couple of times. The way things are right now feel the wrong way round to me.

    Since I probably won't be able to keep my mouth shut if I keep reading this thread, I'll simply ban myself from it for now. So if anyone wants to respond, please PM me or something. And I'll go and get a blog soon.

    Again, sorry Selkirk.

  3. #53
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Selkirk
    they're not intuitive
    Perhaps they are, because they are 'simple'; easy to come up with and therefore not necessarily very precise, not precise at all in MVC's case.

    Quote Originally Posted by McGruff
    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?
    Not necessarily. For example, you might have a domain object that reads data from some other domain objects to perform a calculation. But loosely speaking you could say so. Also very loosely: you could consider code that tells the domain model to change its state to be Controller code (C in MVC) and code that reads from it View code. Although it's possible for a Controller to read from the domain model as well.

    Hmm, on second thought, the above paragraph is so abstract that anyone can give his/her own interpretation to it and what I said probably has no meaning at all Guess that's a problem that's present in all MVC discussions we've had so far.

  4. #54
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    CP: Thanks for the reply. Not too abstract - made sense to me although perhaps that might not be the best of litmus tests... I guess the rule is anything can read but only the controller can write (or should that be send a "write" command?).

    Possibly I do not have a very well-defined idea of what a doman model is - which doesn't help much in these discussions.

  5. #55
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)

    Thumbs up

    Hi...

    Quote Originally Posted by Selkirk
    I could really use some feedback, comments or questions about areas that aren't clear.
    It is pretty obvious that you understanding of MVC has advanced a great deal. Certainly miles ahead of me. An excellent summary of the state of play (best I've ever read).

    Despite being miles behind it would be completely out of character for me not to comment anyway...

    I totally agree with the MMVC point. The "M" in MVC has nothing to do with the domain model layer in application architecture. The obvious split here is to move your web app. to a SOAP service. Your domain objects stay, but your sessions, shopping baskets, etc. do not. It is more of a user interface model in MVC. MVC makes up what I tend to call the "presentation tier", but most architecture books call it the "application tier". This wording rather knackers the concept of "application" and so I hate it.

    In document/view the view can write back to the model, in MVC it cannot. This is difficult to represent with UML arrows because they carry the meaning of visibility rather than the tighter meaning of read only. Widgets seem to naturally follow document/view, but this may just be tha way I've written them.

    Actions are clearly the building blocks of the site navigation in most frameworks. I am not sure the filter chain is the last word though as it seems a bit restrictive. If an error occours (bit like an exception or redirect) the whole command execution path will have to restart. In a way you want to broadcast your action name looking for a receiver to deal with it. The structure of the receiver net could determine the navigation of the application. An action/catch pattern?

    I have the same problem with MVC as I have always had . Despite an excellent explanation it has still told me nothing about how to write a web app. I have learned a bit more about action filter chains and I fully endorse the use of Action as an interface, that is definitely useful. It seems to me that it is always the peripheral discussions that shed the light. If you had written a page on filter chains in Mojavi/Struts/Phrames and why they are a good thing, I think I would have benefited equally well without any reference to MVC. If our discussions were centered on the Command pattern, how much more productive would they be? MVC seems to be clouding our vision and slowing real progress.

    Great article though .

    yours, Marcus

    p.s. Jeff, in your posts you are taking Naked Objects well out of context . It was designed originally as a system for rapidly validating business object models by giving the domain experts code they could use straight away. It is the exact opposite of "task" driven interfaces exactly because it is applicable to situations where the "tasks" are not clearly defined. The idea is to allow expert power users to manipulate a complex system with few restraints. The places where it has been most successful (the Irish Benefits system and the Nowegian Energy Exchange system) are where highly skilled people were involved. Its not designed for novices.

    It also has nothing to do with a data model. Naked objects is about adding fine grained behaviour to an object model. You certainly won't have to update disparate tables. The system you describes seems simply to have been badly written, having managed to code few business rules or domain concepts.

    Naked objects is simply optimised differently, gaining rapid development and fast model refinement in return for a fixed "full on" user interface. It does not claim to be broadly applicable (so it is rather unfair to attribute blame to it outside of its scope).

    What makes it fascinating is that it is completely original and very successful in its area. You can build a desktop application astonishly quickly.
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  6. #56
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    I totally agree with the MMVC point. The "M" in MVC has nothing to do with the domain model layer in application architecture.
    It's probably just a difference of emphasis, but I would say it has everything to do with the domain layer. The Model either hides or represents the domain logic. And the basic separation between domain and presentation in a layered system exist for the same reason as the Model / View separation in MVC. It's the same thing, but seen from different angles, since MVC deals specifically with the user interface, wheras layering deals with the system as a whole.
    Quote Originally Posted by lastcraft
    The obvious split here is to move your web app. to a SOAP service. Your domain objects stay, but your sessions, shopping baskets, etc. do not. It is more of a user interface model in MVC. MVC makes up what I tend to call the "presentation tier", but most architecture books call it the "application tier". This wording rather knackers the concept of "application" and so I hate it.
    Eric Evans (Domain-driven design, page 70) has both a an application layer and a presentation layer. That seems not entirely unreasonable to me.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  7. #57
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Azmo
    First of all, I'd like to apologize to Selkirk for derailing his topic, and turning a topic about one of the better MVC articles into a whinefest.
    I am sorry for the terse reply. I was kinda busy. You haven't derailed this topic, Azmo. I think your posts are relevant to the topic. I just think that distinguishing between the user and the user agent doesn't gain anything from the perspective of structuring your server side programs. Its a distinction without a difference.

    Quote Originally Posted by Azmo
    The problem I have is mostly linguistic I think (it's taken me some time to realize this). IMO class names should give a good indication of the behavior and responsibilities of their objects. I don't think the terms 'Model', 'View' and 'Controller' fit this criterium; they're not intuitive.
    There is a HUGE linguistic problem with MVC. Part of what a pattern should do is supply a system of names for the components of the pattern. This has been brought up in other MVC threads here: where is the controller object? Where is the view object? Where is the controller object? The controller is an especially unfortunate and overloaded name, but as I hope I conveyed in my previous post, even the seemingly non-controversial model name and definition is not clear. I've been trying to work on names in the WACT MVC implementation by actually naming components after the MVC layer that they are in. Its definately not perfect.


    Quote Originally Posted by Azmo
    And finally, I believe the MVC pattern is being used to solve the problem of web applications. But as far as I understand things, patterns are supposed to emerge naturally after the problem has been solved a couple of times. The way things are right now feel the wrong way round to me.
    I agree that patterns ermerge naturally, but they are also sharpened by descriptions of them. I think MVC has re-emerged so many times that we can hardly describe it because of the variation. Part of the MVC discussion also has to do with applying the traditionally GUI based pattern to a new domain: the web.

  8. #58
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    It is pretty obvious that you understanding of MVC has advanced a great deal. Certainly miles ahead of me. An excellent summary of the state of play (best I've ever read).
    Wow. Thank you. I know that writing the the wiki page and participating in the MVC discussions here has helped me.

    Quote Originally Posted by lastcraft
    Widgets seem to naturally follow document/view, but this may just be tha way I've written them.
    perhaps so. Both .Net and JSF ended up with document/view and widgets.

    Quote Originally Posted by lastcraft
    Actions are clearly the building blocks of the site navigation in most frameworks. I am not sure the filter chain is the last word though as it seems a bit restrictive.
    There is a bit more to the concept of an action chain than there is to a filter chain (as in intercepting filters). Struts 1.1 doesn't really implement the concept of an action chain (ala webworks) and thus neither do most of the clones. This is an area which I will try to look into more.


    Quote Originally Posted by lastcraft
    If an error occours (bit like an exception or redirect) the whole command execution path will have to restart.
    I think the difference between an action chain and a filter chain is that the action chain includes a mechanism to reporting exceptions and changing views.

    Quote Originally Posted by lastcraft
    In a way you want to broadcast your action name looking for a receiver to deal with it. The structure of the receiver net could determine the navigation of the application. An action/catch pattern?
    Struts, its clones and JSF as well have a level of indirection between the result of an action and the "next step."

    Quote Originally Posted by lastcraft
    I have the same problem with MVC as I have always had . Despite an excellent explanation it has still told me nothing about how to write a web app. I have learned a bit more about action filter chains and I fully endorse the use of Action as an interface, that is definitely useful. It seems to me that it is always the peripheral discussions that shed the light. If you had written a page on filter chains in Mojavi/Struts/Phrames and why they are a good thing, I think I would have benefited equally well without any reference to MVC. If our discussions were centered on the Command pattern, how much more productive would they be? MVC seems to be clouding our vision and slowing real progress.
    Perhaps MVC is better as a framework pattern than as an application pattern. It may be too complex to implement in an application without a framework. It certainly is complex enough and brings together so many other different patterns.

    My description is certainly very abstract. The abstract discussion and description may make more sense if you have a concrete example to work with. I have the benefit of having the MVC support built into WACT and a non-trivial application in production using those capabilities of WACT. It is easier for me to see which parts are useful and which parts of the description need more work and which parts of the WACT implementation need more work.

    Moving this application from a naive MVC structure to one modeled after Struts was a definate improvement in the code. It was extremely noticable. Yet, there are still rough edges with the WACT MVC framework and even with how struts is structured. These are what I am trying to work on now.

    I think it is good to have the app and framework evolving together. Its frustrating, though when I have to program features for the app that I know would be easier if I did more work on the framework, but can't because of time constraints. And then on the opposite side have to do massive updates on the app when I do make the framework changes to keep them in sync.

    Quote Originally Posted by lastcraft
    p.s. Jeff, in your posts you are taking Naked Objects well out of context
    Fair enough. I'll be more careful.

  9. #59
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Well, I've done more thought on the relationship between the view and controller. Specifically:

    Should a heirarchy of controllers components mirror the heirarchy of view components or should they both be merged into the Document/View?

    Consider a button in a complex heirarchical view with the following lineage:

    Application > module > sub module > page > frame > portlet > panel > form > panel > button

    Now, assume that there is a multiplicity of components at every level: multiple forms per page, multiple submit buttons per form, etc.

    JSF and dotNet are both capable of representing a heirarchy of components such as this, but mimicing GUI design, they do not distinguish between the controller and the view. The input (HTTP request) is distributed across the view components that require interaction with input. The controller functionalityis contained in the framework and in the view components.

    The problem with implementing this in PHP is shown by the example of a form page that shows a thank you page with successful.

    In that request, the view heirarchy for the form will have to be instantiated to handle the incoming POST. Then, the view heirarchy for the outgoing response will also have to be instantiated to handle the outgoing thank you page. The thing is that none of the view capability of the form page was used during this request and none of the controller (input) capability of the thank you page was used during this request.

    This is not a problem for dotNet or JSF because they keep both component heirarchies in memory between requests. However, a PHP implementation would have to re-build both heirarchies during the request, even though only half the capability of each heirarchy was required for the request.

    Now consider a MVC implementation in PHP which separated the C and V. This implementation would then only have to re-build the controller heirarchy for the form page and re-build the view heirarchy for the thank you page upon receiving this type of request.

    Now look at struts. Struts is view agnostic. Thus, the struts controller components cannot mirror the structure of the view. Struts divides the controller into the following classes:

    ActionServlet and ActionMapping (together considered the front controller) along with the Action.

    Since the Action was historically the official point of extension, many varieties of actions arose:

    ForwardAction, IncludeAction, DispatchAction, LookupDispatchAction, SwithAction, BaseAction, SuccessAction, RelayAction, ParameterAction, FindForwardAction, BaseHelperAction, ProcessAction, AttributeExistsAction, and RemoveAction.

    The names of these controller components aren't really meaningful, are they? The interesting thing is that if you look at the purpose of these various components, it turns out that you can use them to structure your controller layer to exactly parallel your view layer what ever that is.

    The problem is that instead of the controller components being connected by a simple heirarchical structure, they are connected through a level of indirection with the front controller as a state machine. This obscures their relationship. You certainly can't tell by the names. DispatchAction can be used to group related operations, while LookupDispatchAction is used to decode buttons. RelayAction or FindForwardAction are used when there is more than one submit button on a form. Because of the layer of indirection in representing the controller structure, All of the struts framework supplied action classes ended up with names indicative of indirection or going somewhere else, instead of being named based on their purpose in the application. This is bad.

    (Most of the struts clones are not mature enough to have such a rich set of components in the framework, and so they leave it to their users to re-implement these concepts.)

    (I've also noticed that struts and its clones don't provide a view class, so many of the example applications I've seen re-invent one in the application as a special action subclass and then use the standard struts technique of indirection through the config file to express the relationship.)

    So if you consider the JSF/dotNet model to be no degree of freedom between the V and C, while struts is too many degrees of freedom between the V and C, then I think the best answer for PHP (or at least WACT) lies somewhere in between. This means separate V and C and parallel hierarchies.

    Note that with parallel heirarchies, not every V component will have a C (panel has not need for input) and not every C component will have a V (a module or application component will delegate to lower level components for output).

    I hope to do some experimentation soon to prove out the idea.

  10. #60
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Might be slightly off on the matter of fact about your article Selkirk, but I'm not too happy with this part you've brought up

    This is not a problem for dotNet or JSF because they keep both component heirarchies in memory between requests. However, a PHP implementation would have to re-build both heirarchies during the request, even though only half the capability of each heirarchy was required for the request.
    I don't think it's a good idea (for PHP developers) to bring in design issues used by DotNet (for example) for planning design for PHP, as you've pointed out

    People from a Java background might think they can design and develop PHP easily knowing about a Java framework for example, unknowingly make a complete mess of things since PHP is entirely different.

    Should a heirarchy of controllers components mirror the heirarchy of view components or should they both be merged into the Document/View?
    Not sure of this one myself, but wouldn't there be a case of a Controller having more than one View ?? I don't mean in regards to building a complete template from several either (Composite View)

  11. #61
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Selkirk
    Perhaps MVC is better as a framework pattern than as an application pattern. It may be too complex to implement in an application without a framework. It certainly is complex enough and brings together so many other different patterns.
    It all depends on how you think about it. I think about MVC mainly as a sorting principle. Put M, V and C in different places. That's not necessarily complex. It only becomes really complex when you bring in the details from rich-client GUI MVC. I consider that both unnecessary and irrelevant.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  12. #62
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Selkirk
    DispatchAction can be used to group related operations, while LookupDispatchAction is used to decode buttons. RelayAction or FindForwardAction are used when there is more than one submit button on a form. Because of the layer of indirection in representing the controller structure, All of the struts framework supplied action classes ended up with names indicative of indirection or going somewhere else, instead of being named based on their purpose in the application. This is bad.
    Thanks for pointing this out. It sure looks like a mess to me. I've never studied Struts, but this is surprisingly bad. I'm sure they had reasons for calling it DispatchAction instead of ActionGroup, but those reasons probably come from having their noses too close to the technical details, rather than the concepts.

    As for DispatchLookupAction (I'm guessing this is what you call LookupDispatchAction), I just don't get the point.
    Quote Originally Posted by Struts in Action
    A convenient way to select a dispatch method is by linking it with a button. This can be problematic in a localized application, since the label of the button may change according to the user's locale. For one user, the button may read Delete; for another, it may read Borre.
    Yes, and so? A submit button has a name as well, and this is carried in the HTTP request. It's not as if a controller wouldn't be capable of extracting an unambiguous identifier from that, and calling the correct action. So why would you need to rely on the text on the button (its value attribute), and even "mapping the labels back to their original message keys"?
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  13. #63
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I don't understand the issue either of a VALUE of a button

    The NAME of a FORM element is far more important, and how that is accessed and implemented is the issue more than anything else, unless of course we've missed something ?

  14. #64
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Selkirk
    Since the Action was historically the official point of extension, many varieties of actions arose:

    ForwardAction, IncludeAction, DispatchAction, LookupDispatchAction, SwithAction, BaseAction, SuccessAction, RelayAction, ParameterAction, FindForwardAction, BaseHelperAction, ProcessAction, AttributeExistsAction, and RemoveAction.

    The names of these controller components aren't really meaningful, are they? The interesting thing is that if you look at the purpose of these various components, it turns out that you can use them to structure your controller layer to exactly parallel your view layer what ever that is.
    Another thing that strikes me is this: this is showing the weakness of the Gang of Four Command pattern (a class per command, called Action in this case) for Web applications: It invites using inheritance in cases where it would be more appropriate to have a completely separate class to do the work. Or letting the Web handler do it.

    Better to put several commands in one class in the first place, in my opinion. That invites a more "normal" style of refactoring.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  15. #65
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Better to put several commands in one class in the first place, in my opinion.
    Not in my view, as there are obvious advantages to the pattern.

    This pattern is normally implemented along side a Front Controller, where it's best suited. Now, if you have an individual class per action/command, then you are more able then to govern any specific task to be done for each action/command as I see it ?

    Sure, you end up with a lot of classes, but with some repeatitiveness, you can leave this to a base class for the most part anyways

    If you have several actions/commands to one class, then chances are these will bloat at a later date once you need to add more functionality for one example why I disagree with you on this point


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
  •