I'm fairly new to MVC. In my MVC app when the client initiates a View's javascript function call, I am proceeding where the javascript first calls a method in the controller (via ajax) where it updates session data/database data (a non-action controller method), then a second calls (but part of the same javascript) an action method in the controller to get another view. I am doing this because I think it provides a clean separation between my session state updates/database updates (in the first call) and my viewmodel updates and view push (in the second call). I can then always depend on the session data being correct and ready to be applied to a viewmodel in an action method. Is it a "good" practice to use this approach in general? TIA.
Related
Does the ZF2 forward() controller plugin fire off a new request cycle? Or part thereof?
I am writing a ZF2 MVC application with widgetized content. The widgetized content is exposed via its own controller action because sometimes I need to hit it with ajax.
When I need to incorporate the widgetized content as a sub-view of another action (i.e. on a full page load), that action is using the forward() plugin to get the widgetized content. If it's going to introduce a significant overhead though I will go straight to the service layer instead (even though that approach is less DRY).
I realise that a performance test will answer this question for me, but I'm a few weeks away from being able to run such a test.
EDIT: when I say 'new request cycle', I mean the ZF2 MVC request cycle, i.e. route, dispatch, etc. Intuitively I would doubt it fires route a second time, but it could start the cycle from dispatch. I'm asking the question because I know that in ZF1 it triggered a who second cycle, which was a real performance drain.
There are two options to "forward". Understand php is as server side language a processor to grab an incoming request and return a response.
That said, the first "forward" uses in-framework forwarding. This means there is only one request and one response. Internally the framework calls one controller action and then another one. Zend Framework calls this method forward.
The second "forward" is a real redirect, where the first response contains a Location header and the 302 http status code. This results in a second request and consecutively in a second response. Zend Framework calls this method redirect.
So with above, the forward you talk about in your question does not involve any sessions or route match parameters, since the second call to an action is within the same php process, so all variables are already known.
Is it possible to forward data to another controller/action in Zend 2?
I am trying to use portlets based on MVCPortlet on Liferay 6.1.1, and it does not behave as I was expecting. My portlets are supposed to be independent, but are not...
My need:
I have a first portlet A with a form.
I have several instances of a portlet B, based on MVCPortlet.
When the form is submitted, the portlet A launches an event, and all portlet B receive this event. When a portlet B receive the event, it must build an URL, connect to it and read data from it, and display the result.
My B portlet is based on MVCPortlet, is instanceable, ajaxable and with a render-weight of 0, for having a parallel processing and displaying of all instances of portlet B.
But it does not work well:
1) I could not do the processing of the URL in the event processing, as all events reception (one per instance of my portlet B ) are processed in the same thread. So in the event I just set a renderRequest parameter, so the jsp page automatically use an ActionURL to call the action processing in my portlet.
This action builds the URL, use it, process the data, and redirect to the result display page (response.setRenderParameter("jspPage", "/html/display/results.jsp")).
2) I was expecting each portlet to be independent from the other, but they are not. There is only one instance of the MVCPortlet, shared by all portlets, that greatly surprised me. The portlet session is also shared by all my instances of portlet. The action method is executed by different thread, that is good, but the rendering of portlets can be blocked by actions processing of other portlets. One portlet can provoke the whole page refresh. All things that I wanted to avoid by having instanceable, ajaxable and render-weight with 0...
I wonder if there is something wrong, if it is normal to have only one instance of the class extending MVCPortlet, etc. Or if there is a best way to have the desired behavior.
1) I'm not completely sure what you're doing here: Event handling is AFAIK undefined in terms of parallelism, so it's normal behaviour that all events are handled sequentially in the same thread. However, I don't understand what you mean by the ActionURL part of your description. You're able to change state of your portlet in the eventhandler, but not during the render phase. Typically every request handles only one action, multiple (as necessary) events, then renders all portlets. Do you imply that this is followed by an action on every single B-portlet? That's unexpected and I'd rather recommend you do either the processing in your event handler or trigger it to asynchronously run in the back while continuing through the event processing (especially when it takes time)
2) The portlets are independent of each other, however, not every portlet maps to a single Java object. In fact, the implementation is just like in the servlet world: There's only one object that's not supposed to have any state. Almost all instances of member variables in a portlet (or a servlet) are a sign of misunderstanding the API: The whole state of the portlet is coming in through the various PortletRequest and PortletResponse objects, nothing shall be kept within portlet member variables.
Based on your intent to asynchronously render all B portlets, I assume that rendering might take a while - eventhandling should continue as quickly as possible. Otherwise there's no point in rendering asynchronously if the whole result is already there.
I have a MVC3 razor application. I have views which are made of multiple partial views. Controller will have to load the data to all the partial views with the help of different service calls.
Now if any of the service call fails, the entire view should not fail - it should continue to show other partial views. and should show error message for the partial view which failed.
Please note here that I do not want to add individual try catch blocks all over the code. Is there any way to achieve this using global error handling?
If loading data for those partials is an I/O intensive task such as network service calls and order is not important (can be done in parallel) => asynchronous controllers seems like a good fit for your scenario. You could register multiple asynchronous operations in the controller action and upon success/failure load the corresponding result/error message into the view model.
One easy alternative here is simply include multiple ajax calls to load the partial views on the client side. If one fails, no problem as it is it's own separate request. Use jQuery's .get() method once your document loads. You can then include multiple wait images and handle each error separately - however you want.
I've currently got a controller which passes a model to a view. The view will be making AJAX calls to the controller to make updates to the data rather freqeuently, and the model makes for a rather nice arrangements to make these updates.
I know that making changes to the database in the controller is bad form, and I would like to avoid doing it. However, creating a model on every call and handing the update data off to it, although it seems more correct to me, takes longer on each request, as the model needs to be initialized. Since the user is blocked from interaction with certain elements on the page during the update, this time can really add up across dozens of updates.
Which method is best? Simply making the updates in the controller to keep the application as interactive as possible, or initializing an instance of the model on every request to handle the update at the expense of speedy request processing?
I would suggest optimize your model and/or create a lighter version of it.
Why is your model taking too long to initialize? Is the initialization loading things that you don't need when called in this particular case?
Bottom line, I would move the saving logic to a model but would make sure the model is fast and optimal.
Background:
http://www.hanselman.com/blog/HanselminutesPodcast188ASPNETMVC2BetaWithPhilHaack.aspx
Start from 27:15,RenderAction has been discussed at 28:43 that a RenderAction will not be part of Asynchronocity as an asyncronous action method called.
(Let's say your home portal index action calling 1.GetNews 2.GetWeather 3.GetStock asynchronously.You have have a RenderAction displaying user recent posts on the same view. (GetUserRecentPosts))
Questions
What if RenderActions themselves are asynchronous ?
Would GetUserRecentPosts be called only after home index completed its action even though?
Should RenderActions be rendered asynchronously on a view by default?
I don't think you can do this successfully. The point where you could benefit from asynch processing has already passed when your views start rendering. The MVC pipeline that sets up the begin/end methods has already completed and the View has no way to get back into it on the same request. Seems like you may be stuck with synchronous processing OR devise some way to retrieve all your data up front and cache it in TempData or something for rendering.
Lift framework in Scala is probably the only one that I am aware of that has parallel partial actions which will not block the rendering of the main content but will use Comet-push to deliver partial view content for those blocks which may take a while to get data for.
to use it, just wrap a block in your view inside a parallel node
<lift:parallel>
//this is where Html.RenderAction("GottaFetchNetworkDataFromSomewhereView");
//this is where Html.RenderAction("GottaFetchNetworkDataFromSomewhereView2");
// would go
</lift:parallel>
Lift will also take care of connection starvation of your page to manage http requests in the appropriate manner so that browser pushes are not "waiting 'round".
Unfortunately, ASP.NET MVC has poor Comet support. There's not much outside of Asynchronous Controllers, which is an improvement but not as elegant as, say, Akka's framework suspend() method for long-polling.