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.
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.
Looking through my business requirements, the web analytics team wants to make s.T() 'page load' calls when a user navigates to different sections on the same long ass page. This is also supposed to happen when they scroll to or through this content. I feel like this should perhaps be completed with a link tracking call, is that correct? Is there a recommended approach for handling this scenario? Are there any well document drawbacks to faking pageload omniture calls?
There's absolutely no issues calling s.t() multiple times, as long as you want each of those calls treated as a page view.
Really the only differences between s.t() and s.tl() are as such:
s.t() calls increment page views while s.tl() calls do not
s.t() calls collect pageName and pageURL while s.tl() calls do not
s.t() calls send all defined variables while s.tl() calls only send variables defined in s.linkTrackVars
Based on your business requirements, if you want additional page views to be incremented as they scroll through it, by all means use s.t(). If you want page views to only increment on actual page loads, consider using s.tl() calls.
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.
When a screen has multiple interacting Ajax controls and you want to control the visibility of components to react to these controls (so that you only display what makes sense in any given situation), calling target.addComponent() manually on everything you want to update is getting cumbersome and isn't very maintainable.
Eventually the web of onClick and onUpdate callbacks can reach a point where adding a new component to the screen is getting much harder than it's supposed to be.
What are the commonly used strategies (or even libraries if such a thing exists) to avoid this build-up of complexity?
Update: Thank you for your answers, I found all of them very useful, but I can only accept one. Sorry.
In Wicket 1.5 there is an event bus. Each component has onEvent(Object payload) method. With component.send() you can broadcast events and each component can check the payload (e.g. UserJoinedEvent object) and decide whether it wants to participate in the current Ajax response. See http://www.wicket-library.com/wicket-examples/events/ for a simple demo.
You could add structural components such as WebMarkupContainers, when you add this to the AjaxTarget everything contained in it will also get updated. This allows you to update groups of components in a single line.
When I'm creating components for a page I tend to add them to component arrays:
Component[] pageComponents = {
new TextField<String>("Field1"),
new TextField<String>("Field2"),
new TextField<String>("Field3")
}
As of Wicket 1.5 the add functions take array parameters [1]. Therefore elements can be added to the page or target like this:
add(pageComponents);
target.add(pageComponents);
Components can then be grouped based on which you want to refresh together.
[1] http://www.jarvana.com/jarvana/view/org/apache/wicket/wicket/1.5-M3/wicket-1.5-M3-javadoc.jar!/org/apache/wicket/ajax/AjaxRequestTarget.html
Well, of how many components do we speak here? Ten? Twenty? Hundreds?
For up to twenty or about this you can have a state controller which controls which components should be shown. This controller sets the visible field of a components model and you do always add all components to your requests which are handled by the controller. The components ajax events you simply redirect to the controller handle method.
For really large numbers of components which have a too heavy payload for a good performance you could use javascript libraries like jQuery to do the show and hide things by the client.
I currently use some sort of modified Observer-Pattern to simulate an event-bus in Wicket 1.4.
My Pages act as an observable observer since my components don't know each other and are reused in different combinations across multiple pages. Whenever one component receives an Ajax-event that could affect other components as well, it calls a method on it's page with an event-object and the ajax-target. The page calls a similar method on all components which have registered themselves for this kind of event and each component can decide, on the base of the supplied event-object if and how it has to react and can attach itself to the target.
The same can be archived by using the wicket visitor. I don't know which one is better, but I think that's mainly a matter of taste.