Navigate to previous page

Written by Paulo Vale on Sunday, February 17, 2008

When developing an application we must provide intuitive navigation. When a user enters a page and it's presented with "Cancel" button, clicking this button should redirect the user to the page he came from. To achieve this, we can create a branch referring a page number. However, fixing a page number isn´t the best solution because the origin page can be variable.

I've tested some solutions using javascript:history.back() or decoding the referrer url using owa_util.get_cgi_env('HTTP_REFERER') among others, but ended with a self made solution. This solution consists in having an PL/SQL application process executed "On Load Before "Body" Region(s)" updating an application item wich stores the last page visited by the user.

So let me elaborate, step by step:

1- Create two application items.

2- Create a PL/SQL application process.


3- Go to you page and edit the branch linked to the CANCEL or SUBMIT button.

That´s it. Please feel free to comment or add an alternative solution.

Related Posts by Categories

Widget by Hoctro | Jack Book
  1. 11 comments: Responses to “ Navigate to previous page ”

  2. By Anonymous on February 29, 2008 at 3:17 PM

    Does this still work if you have 2 levels of pages? E.g. Cancel on 3 gets you to 1 or 2 depending on which one you came from and Cancel on 5 gets you to 3 or 4. If you start at 1, go to 3, go to 5, can you ever get back to 1? Maybe local previous page item?

  3. By Paulo Vale on March 1, 2008 at 1:01 AM

    Hi anonymous,
    As it is, the code woudn't work for that scenario. However, I think you could do it creating an aditional application item and adapting the process code.

  4. By Andy Steel on June 25, 2008 at 4:21 PM

    It doesn't work particularly well with multi-page Wizards either.

    Say you're on Page 1 and click on a button to take you to the first page of a 5 page wizard. All the cancel buttons on the wizard should take you back to page 1 in my opinion.

    If you cancel on 4th page of wizard, it'll take you back to 3rd page. Cancelling that page will take you back to 4th page of wizard.

    I think you need to limit the number of cancel buttons, employ this technique sparingly and also use something different on Wizard pages.

    Perhaps the first page of the wizard could store the calling page and then all other pages of the wizard use that page item when cancelling as opposed to the application item.

  5. By Paulo Vale on June 25, 2008 at 4:55 PM


    For your wizard example, if all cancel buttons should return to a fixed page, I don't see the need to use a dynamic system.

    Maybe you should just put page number into the branch, instead of a calculated one.

  6. By valesremedy on May 6, 2009 at 5:40 PM

    I did find myself w/the same problem, however, I found a pretty simple solution.

    1. Make a variable
    (P2_BACK_BUTTON) and assign it the page of origin (in this case "1").

    2. Create a process on submit that calls &P2_BACK_BUTTON. on Page2.

    I hope this helps. If u need SS's let me know.

  7. By Anonymous on July 30, 2010 at 2:31 AM

    You can have the same effect with two Application Computations in place of the Application Process:

    * Compute CALLING_PAGE, sequence 10 Before Header, equal to item ACTUAL_PAGE.
    * Compute ACTUAL_PAGE, sequence 20 Before Header, equal to static assignment &APP_PAGE_ID.

  8. By Anonymous on August 17, 2010 at 5:41 PM

    Web design
    veyr useful, thanx a lot for this blog ..... This is what I was looking for.

  9. By Anonymous on February 25, 2011 at 11:31 PM


    This works perfectly for me if it is from a one region calling page.

    Most of the my pages are using jquery tab. Can you please advise how I can go back to a specific tab that I came from?

    If I hard code the calling page URL, it would be something like -

    Thank you!

  10. By on October 2, 2011 at 2:44 PM

    Anonymous #7 is a good solution
    However and in case the page calls itself, the calling page and the page referred to are the same.
    To avoid this situation:
    * in addition to CALLING_PAGE and ACTUAL_PAGE, add a new application item: PREVIOUS_CALLING_PAGE
    * Compute CALLING_PAGE, sequence 10 Before Header, PL / SQL Function Body
    return nvl (: ACTUAL_PAGE, 1);
    * Compute ACTUAL_PAGE, sequence 20 Before Header, PL / SQL Function Body
    if: = CALLING_PAGE: APP_PAGE_ID then
    end if;
    return: APP_PAGE_ID;

  11. By Anonymous on November 9, 2011 at 3:05 AM

    It might be easier to have one applicatino item 'previous page' and have one application computation after submit that populates this?

  12. By sfauvel on January 12, 2012 at 9:29 PM

    Hi, and thanks for this post. I tried to use your tip, but I must have missed a part of your explanation.

    I have a cancel button, its action is page redirect, and the page number is &CALLING_PAGE.

    WHen I press it, it tries to reach

    Variable is not interpreted. However, if I print its value using a page item with static assignement to &CALLING_PAGE_1, I read the good value...

    Any idea please ??