J2EE patterns: Clarification on MVC Pull and MVC Push
I myself am trying to get my head wrapped around this one since as the leader of www.frameworks-boulder.org many folks have asked me what the difference is and I didn't know. Now that I am trying to understand the different definitions it isn't getting much easier specially when different projects contradict each other! I'm going to try and take a stabe at it and I hope you all response to support or correct these definitions.
- Posted by: Kris Thompson
- Posted on: October 29 2003 13:27 EST
MVC Push: This is where the framework creates context objects what are "pushed" or made available to the templating language like JSP's allowing them either via tags or scripting to get their values and dislay them on the page. Struts and Expresso a good examples of this. In Expresso you create Output objects that are made just for rendering the View
MVC Pull: This is where you have one or a few objects that are made available to all templates. The big difference is the java developer does not need to create any sort of output object, they just make backend model objects available to the View templetes. WebWork and Maverick are a good example of this, they a provide accessor methods(getters) in their Action classes that allow the View to "pull" whatever they like as long as they know of the API for that Action. However Jucas, http://jucas.sourceforge.net/index.html, also claims to be a MVC Pull but I won't consider them to be similar to WebWork or Maverick at all, do we need another definition to explain the difference?
Some also may argue that the MVC Pull or MVC Push are really defined on what templating View you use, NOT what presentation framework is choosen. For example, XMLC is very much MVC Push in that it pushes all data/HTML to the browser. So on the flip side JSP Taglibs are MVC Pull in that they pull data from the Context as needed.
I don't think there is a right or wrong but clarification to the general public is what is most important!
- I think you'vr got it... by Jason Carreira on October 31 2003 22:00 EST
- Push vs. Pull Template data population by Jeff Moore on November 01 2003 05:18 EST
- Push-->Pull-->MVC by vimarsh vasavada on December 09 2003 05:10 EST
- Clarification on MVC Pull and MVC Push by Kristof Jozsa on January 14 2004 06:45 EST
- Push and Pull: jakarta Turbine by Bo van Weert on February 27 2004 10:46 EST
- Much higher level than that... by Steven Lohrenz on June 17 2004 09:22 EDT
- Much higher level than that... by James Watson on June 17 2004 10:10 EDT
Much higher level than that... by Steven Lohrenz on June 18 2004 09:30 EDT
Much higher level than that... by James Watson on June 18 2004 12:04 EDT
- Much higher level than that... by Steven Lohrenz on June 22 2004 08:01 EDT
- Much higher level than that... by ale gos on September 12 2004 09:02 EDT
- Much higher level than that... by James Watson on June 18 2004 12:04 EDT
- Much higher level than that... by Steven Lohrenz on June 18 2004 09:30 EDT
- Much higher level than that... by James Watson on June 17 2004 10:10 EDT
- yellowfin by matt coleman on January 31 2013 00:34 EST
That looks like a pretty good explanation... WebWork also allows "hierarchical pull MVC", which means you can push more objects onto the value stack in WW and have them be available for pulling from the JSP tags...
What does your def have to do with the concept of hierarchical? WebWork seems to be a classical MVC Pull.
you said MVC Pull model is where the framework creates context objects what are "pushed" to the templating language so it can display them on the page. Please I would like to know how Struts follows a Pull model. Which are the context objects being pushed in its case.
Thanks a lot.
There is a discussion of Push vs. Pull template data population here (from a PHP perspective):
Thanks for clarification.
We are using PULL MVC model.We are evaluating Struts and WebWork and other frameworks.Have already visited wafer.org.it has helped but still have few doubts regarding selection.
Our present architecture:
We are comfortable with existing except one thing : Manitainibility.We have a template that looks like :
YOUR PROFILE HAS BEEN UPDATED SUCCESSFULLY.
This is my understanding..please clarify..about principl +/- of 2 architectures.
1. Central Entry Point: Auth,Logging,Encoding etc. functions are centralized.
1. View level IN-FLEXIBILITY as Data to be shown is provided by Servlet/Action classes.What if the View needs to show new data or remove existing data.I feel the Action class needs to be updated.Consider Pull Model where also we require to change something , but that something is JSP only.We use tags.
1. View level FLEXIBILITY.Just use taglibs as per requirement!
1. Scattered controle:
[ this can be minimized by STANDARD JSP Template with standard Tags.]
2. Repating logic in all JSPs.For a single change one hast to touch almost all JSP.
Now what we are planning is to have PUSH+PULL MVC model.
1.All requests are given to FrontController as per Struts and WebWork2..
2.The JSPs can still PULL if they wish.
3.The JSPs will no longer be responsible to authenticate/authorize
I think WebWork2 also have a similar concept supported by <webwork:action> tag.
In my opinion this will combine the strengths of both approaches.
If i have my personal openion for MVC Push - Pull, i feel that MVC Pull requires lot of coding then MVC Push. As Vimarsh discribed in his mail, they are using different tags for each single task. like various tags for user related actions. instead of that, in MVC Push, a single action class handle all user related action and process business related activities. when user action serve proerly response will redirect to success JSP otherwise error JSP.
I think for fast development of any websystem, MVC Push should be pefered.
Pls advice on this view
WebWork have only one tag called <webwork:action> that can execute any WebWork Action.So no. of tags can still be reduced.There are other ways also by which we can reduce no. of classes.
But central criterias for comparision are in my opinion are :
1. Flexibility for changing UI
2. Managability of Code
This is only possibble if Hybrid approach adopted.
Please comment and correct our understanding.
I'm not sure you grabbed the thing, or maybe I have a different approach defining push and pull. In my explanation:
MVC Pull is the method where the request's rendering phase pulls information directly from the backend. That's what often quicly crafted JSP authors do (and is also the general PHP approach :), and is generally a quite nasty (but quick to develop) approach. One sure note of a solution using an MVC Pull way is when database/legacy system connections are still open during the rendering phase of serving a request.
MVC Push is the method where the request's *processing* phase prepares all data before rendering, and stores this information into some form (data objects, hashmaps, whatever). At the rendering phase, only this data is used, and it gets pushed into the templates.
Therefore, JSP is usually MVC Pull, while Maverick is a very clean MVC Push technology.
Oh well, and dont get confused on Maverick often using the controller class itself as the model which gets pushed into the template.. it doesn't make it MVC Pull!
we are using Jakarta Turbine, which uses push and pull techniques: you can populate the variables in your actions, and from within the template, you are able to call the pushed variables, or call a "pull tool", a well defined API to do some extra call to the backend objects.
We like it, it's very flexible!
I am working on a fairly mature dynamo project and the we are at the point in the lifecycle where we have been asked to be able to run multiple versions of the product in parallel. I have been advocating MVC2, more to the point currently we have a pull model and I think we cannot separate the code base from the view(s) with a pull model. In our code the droplets(tags to non ATG people) call back into the backend code and I cannot see any real way of versioning the system. By versioning I am talking about running a new and old web system in parallel where the front and back end may change. This looks like a view/controller with 'pull' together design restricting designs flexability, does it not?
It is a compromise between these two options,
1) A lot of code in the page which pulls data from the backend, to use within my versioned world it will have to be controll which page to display by version. Then if I want to version the page I need to version the page and all its code. I will then talk to the backend with factories to control the backend versioning via the service interfaces. I also have no option to change the view dependant on the same data(but to be honest this is not a business requirement).
2) MVC2, smaller page code but then also a need to version the model and controller potentially. Again factories at the backend.
Just an aside I would like to break the whole thing up and put workflow in with Java Spaces, but thats another story...
Good morning from New Zealand.
In my understanding push and pull are much more general concepts and that caries over to MVC.
MVC pull is the most common strategy for view->model communication. The model has a bunch of hooks that it exposes. The view is then required to refresh periodically. When it does so, it goes after all the hooks it needs and interprets the data.
MVC push is a little less common. In this strategy, instead of exposing it's data, the model exposes one or more registration hooks. The view is then registered with the model. One or more triggers are then devised which induce the model to apply it's self to the view through an interface specifcation.
In a 'true' MVC architecture (ala SmallTalk or Swing GUI) each view registers with the model which publishes events when it's data is updated. When the view receives these notifications it updates the data it is displaying. This is a 'push' model.
Web applications are constricted by the request-response methodology of http. This means that updates are only diplayed when there is a request (via the view). A page that is being viewed by a user in a browser cannot be updated by the server without a request from the view. Thus the 'true' or 'push' model does not work with web applications. Web applications use a 'pull' model, in which a view is given access to the model and it pulls data from the model after a request.
Thus if you are using a web MVC framework it is MVC Pull.
In a 'true' MVC architecture (ala SmallTalk or Swing GUI) each view registers with the model which publishes events when it's data is updated. When the view receives these notifications it updates the data it is displaying. This is a 'push' model.Generally the model fires an event that lets the view know something has been updated. Then the view goes to the model and 'pulls' the data it needs to display. This is how the JTable / TableModel works. The model doesn't send messages like update the value at this location to this value or add a new row with the following values. At least that's my understanding. In my mind that's a 'pull'.
Web applications are constricted by the request-response methodology of http. This means that updates are only diplayed when there is a request (via the view). A page that is being viewed by a user in a browser cannot be updated by the server without a request from the view. Thus the 'true' or 'push' model does not work with web applications. Web applications use a 'pull' model, in which a view is given access to the model and it pulls data from the model after a request.Thus if you are using a web MVC framework it is MVC Pull.Steve LohrenzI agree with that. But I don't think that Swing is a Push model. A push model is where the view provides an interface to the model and the model tells the view how to display the data. This paradigm is described tangentially in this article:
In my mind that's a 'pull'.The push/pull comes from the direction in relation to the model that notification of updates to the model come from.
The notification is 'pushed' from the model to the view.
The notification is 'pulled' from the model to the view.
I agree with that. But I don't think that Swing is a Push model. A push model is where the view provides an interface to the model and the model tells the view how to display the data.The model in either case should not tell the view HOW to display the data, it should only provide the data to display, as the view's responsibility is the presentation of data.
A push is where views are registered with a model and when the model's data changes events are published to it's views. Then each view can decide if it needs to update the presentation or not. If it does then the view gets the data from the model.
A pull is when the view notifies the model that it is ready to update the presentation and asks for data.
OK. I guess that makes sense. I think there are other ways to look at it. However, if the point is to agree on a standard terminology, I can get on board with what you have described.
Well, I'm just quoting the masters...
various other authors...
Well, I'm just quoting the masters...Really? Can you point me to what you are quoting?
Rod Johnson "Expert One-on-One J2EE Design and Development", The GoF book, "Design Patterns, Elements of Reusable Object Orientated Software". If you haven't read either of those books, then you are missing out on the OO programmer you could be.
I guess it depends on what you form your basis on - Events or Data.
Personally, feel that the "Data" based paradigm mentioned in the PHP article mentioned above (http://wact.sourceforge.net/index.php/TemplateView) makes more sense. IMHO, events are always pushed (broadcasted), never pulled. Only data can be both pushed and pulled...
Can you point me to where "push vs. pull" is defined in GoF DP? I don't remember that section.
"The push/pull comes from the direction in relation to the model that notification of updates to the model come from. "
you are talking about observer pattern which is just a brick in the MVC arcuitecture.
I think push/pull has to do with the way the views retrieve the data from the model. Views in Smalltalk and Swing retrive this info by themselves right before they display to the user. They communicate with the model they KNOW.
In the web context, let's say JSP, where you have java code mixed with the HTML those pages get the data from the model.
In the case of XMLC, each view or page has only HTML and the framework creates a template from it which is given the data to render the view.
FInally, the push/pull discussion ends up on if you have java in the web pages or you dont have any at all...
i agree with what you said here
still not sold on the mvc pull and push..but thats just me