Topic
  • 1 reply
  • Latest Post - ‏2012-04-09T13:04:54Z by mburati
GQWW_Manikandan_A
GQWW_Manikandan_A
11 Posts

Pinned topic Reg setCurrentPage,processPage,processAction issue

‏2012-04-08T14:34:39Z |
Dear,
Would you please elobarate the difference between setCurrentPage,processPage,processAction.

In the exception handler handleException(WebAppAccess webAppAccess) - used the webAppAccess.processPage(webAppAccess.getCurrentPage())
which is causing issue like that duplicate page is displayed in the some place.

If we use the webAppAccess.setCurrentPage(webAppAccess.getCurrentPage()) some place the returned error not displayed in the screen.

Kindly advice how can we resolve this.
Updated on 2012-04-09T13:04:54Z at 2012-04-09T13:04:54Z by mburati
  • mburati
    mburati
    352 Posts

    Re: Reg setCurrentPage,processPage,processAction issue

    ‏2012-04-09T13:04:54Z  
    webAppAccess.processAction can call an action or process a page, depending on the name of the action/page it's passed as an argument.

    webAppAccess.processPage(pagename)
    - when run as a standalone webapp, executes the JSP associated with that page
    - when run as a portlet, sets the current page for that portlet (typically in an ActionRequest) so that when the portal/portlet container calls that portlet with a RenderRequest, it'll know which page/JSP to execute.

    webAppAccess.setCurrentPage(pagename) just sets the current page (if not already set in that request) for a portlet so on the next render request, it'll render that specified page.

    Think of an error handler like a try/catch. The catch typically could be setting error state that the app controller then uses to determine what to show, it shouldn't be executing a page itself because once you're out of the catch, any app logic that would've executed a page before, still will (at least standalone, where you can execute multiple JSPs in a request).

    For example, if your app has an Error Handler that processes a page, but the app also always calls a page as its last action, you could end up with the equivalent of this pseudo-code logic:

    
    
    
    try 
    { 
    
    do some logic here 
    } 
    
    catch error 
    { log it process error page 
    } some other logic process normal page
    


    In that flow, the logic that occurs outside/after the handled error runs after the catch block does, so you end up processing two pages (which will be have differently between standalone and as a portlet).

    Instead, it would be better to just process/save the error state in that catch block / error handler and then use that state to choose which page to display, where you're displaying the page later.

    NOTE - there is one other option to help you out here, which is an input to the Error Handler builder where you can tell it whether to continue processing the rest of the action(s) in the request after the error handler block exits.

    ..mb1