In Struts2 if we have define an interceptor stack and it is called in First in First Out manner.
So in post processing phase what happened if one of the earlier interceptor return a control string which in result render the response to the client.
I want to know that would the left interceptor will be processed or not.
Well it will work like this.
Your action method will only called once the interceptor stack has been called fully.This means that once the first interceptor has been called successfully in the stack it will call the next interceptor defined in the stack and there reference being stored in the stack this chain will keep on calling till the last interceptor in the stack is called
invocation.invoke()
this call is the key to call next interceptor defined in the stack or of this is the last it will call the desired function in your action class.
now in other case suppose some of the interceptor failed say workflow it will return the result as INPUT and will halt the further execution of the interceptor and framework will output the desired JSP/Tempelate to the user.
Than comes the post -processing/cleaning in this case interceptors will be called in reverse order i.e top most or latest executed interceptor will be called first and den so on so.
The idea for this post-processing is to do any clean-up work or any other things which needs to be done (like cleaning up resources etc)
Hope this will give you some idea.
Related
I'm developing an ASP.NET MVC5 application and I have the following situation:
Async controller method calls custom async method 1+ times, each Task object being stored successively in a List
Each custom async method call establishes its own top-level TransactionScope with TransactionScopeAsyncFlow.Enabled
Each custom async method call performs transactional work, then awaits DbContext.SaveChangesAsync()
While this is occurring, the controller method performs its own transactional work within its own unrelated TransactionScope, then awaits Task.WhenAll()
The question arises from using ConfigureAwait(false) when awaiting DbContext.SaveChangesAsync(). Each call to the custom async method starts in the controller method's ASP.NET request context but I don't see any need to recapture it when SaveChangesAsync() returns EXCEPT if it's going to mess up the current transaction. This is important because if an unrecoverable exception occurs in the controller method before I await Task.WhenAll, I need to cancel the async Tasks within a catch block, which means instead of awaiting Task.WhenAll() I'm forced to use the blocking method Task.WaitAll(), which I'm pretty sure will deadlock if the async Tasks are trying to recapture the original request context.
Sorry if this is a repeat question. I did quite a bit of searching and couldn't get a clear answer. Feel free to tell me this is bad programming or whatever, just at least suggest an alternative and leave my mom out of it. Thanks!
If in spring portlet controller, I have one methof annotated with #ActionMapping and another method annotated with #RenderMapping(params = "action=detail"), I see that to come from method #1 to method #2, we do not call the method#2 directly, instead we set a Actionresponse.setRenderParameter("action", "detail") in method #1 and method#2 will pick it up from here.
My first question is what advantages are we getting from separating the render phase from the Action Phase (or should I say Request Phase)? And also why we do not do a direct method call and instead call the method by setting a render parameter?
To answer your questions
Portlets can co-exist on a page. Irrespective of what action you performed on a portlet, the Portal container will invoke render() method on all the portlets to collect the html fragments and aggregate them, in an effort to prepare the whole page view and serve to the browser. Having 2 methods is not only an advantage but an enforcement to implement the aforementioned requirement which separates the business logic - processAction() that may change the state of your system as #Mark Chorley said, which you are aware of the execution "AND" render logic - render() which decides the view to render, which sometimes you are not aware of the execution.
This is simple, why do you call start() rather then run() on a Thread though you can invoke run method directly. There are many reasons why you shouldn't call the method directly
You are not responsible for the aggregation of html fragments from all the Portlets residing on the page.
You are not the one who make the Public Render parameters available in the render() method of the interested Portlets.
Definitely you dont want to take the headache of delegating the Events to the subscribed portlets
This is what portlets do basically. As to what advantage you get - well it allows you to separate your action (typically modifying data) from preparing data for your view.
Both Action and Render are different stages of a single request. Action requests precede Render requests as you say. "Request phase" sounds a confusing term to me. Action Phase and Render Phase are more helpful terms.
Why you don't call it directly - well the portlet container will do it for you. Also you must remember that the render methods will be called on all the visible portlets, but the action request will target only your portlet.
So given that the portlet container is guaranteed to call all the render methods on all the visible portlets, it doesn't make sense to call the render method manually on one portlet just because the action request targeted it.
If you only have one portlet visible this is perhaps less clear. It makes more sense when you have multiple portlets on a single page.
I have a requirement for formatting some variables before going to action and reformat after action executed but before rendering. I added a interceptor. I format the action variable value before invoke method called and reformat after invoke method called. Changes made before invoke method in interceptor are effective in Action execute method. But the changes made for reformat on action variables after invoke method executed are not seen when the page rendered. Will the framework not take the changes done in Action variables in interceptor's post processing section? Please help.
By the time invoke returns control to the interceptor the result has been rendered.
You need to implement a PreResultListener as described in the big yellow box on the "Writing Interceptors" doc page.
ZF2 question here.
I like the event driven stuff in ZF2.
Here's my goal.
I want to start the session, using a database table, and I want to be thrown to the error/error template if for some reason there is no database connection.
Here are some ways I thought about doing this. I could attach to the application 'route' event and start the session right before the route matching happens, or right after. There are no TRY catches though, in the Mvc\Application.php file so I don't think this is the place to do it.
There IS however a try catch block around the CONTROLLER's dispatch method being called. And I noticed that the controller has it's own internal 'dispatch' event it triggers.
So the other possibility is that I should attach to this internal controller dispatch event and setup my session THEN before the controller's action methods actually execute, and thus before they NEED the session.
So, how can I attach to this internal 'dispatch' method? Or how else can I make it so that any database connection exceptions go to my nice Exception page rather than getting spewed out as a normal php error without any exception handling???
There is no more init() method on the controller because this is functionality events are supposed to provide.
Thank you for the help.
FYI : I tried attaching to different events, such as 'bootstrap', 'loadmodules', 'loadmodules.post'. All I did in the attached method was throw an exception to see if I would end up in the nice error page I have but I didn't have any luck. I ended up debugging it and found this internal controller 'dispatch' method. The controllers get their own internal event manager. At least that's what I gather from my debugging. I might be wrong so correct me please!
I added a ParameterHandler to my application's main window so I can catch and process custom get parameters in my url. However, the presence of one parameter reloads the first page of my application, for some reason building this page triggers the handleParameters method again, this time with no parameters passed. If left unchecked (e.g. no ifs) the page's elements will just replicate themselves on top of themselves over and over again.
I suspect it has something to do with my main windows's addComponent method.
How can I stop it from doing that?
I completely forgot I still had this question open. I found that the problem was that the method got triggered for both get and post type parameters, and this is what caused the unexpected output.
I already implemented an HttpServletRequestListener because I used Vaadin's ThreadLocal pattern, so I just filtered all GET parameters out of the request object in one of the implemented methods and went from there.
debug your application and have a view at the call stack of the handleParameters method