0
votes

I'm developing an application in Oracle Application Express (APEX).

First page contains list of projects as a tabular report.

Clicking any of the rows forwards to the next page, where records can be edited. I've implemented it with following settings:

  • Link column: link to custom target
  • Target: Page in this application

Until this is fine.

My problem is how to pass actual report to the next page?

My table, which is the basis of the report has primary key (ID), and also owner & title combination is unique. Currently ID column is not included in the report.

Also the second page doesn't currently contain field showing ID, as this information isn't important to the users.

I know I could set ID column in report, and create a read only (even hidden) text box in the next page, however I'm looking for a more elegant solution. What is the standard way to solve this?

2

2 Answers

1
votes

I wonder if you are asking: "How do I pass a value from page 1 to page 2 so page 2 can use the value to do a query and present the results. If so, here is how it's done.

On page P1, the report, for example, select the attributes for the report region under the region in the Rendering pane on the left of the page designed.

Under Attribute Properties on the right side, look for Link Column and set it to "Link to custom target". Then click Target.

Select the page and then in the Set Items section, on the left, under name, select the PK ID field to receive the passed value ex: P2_ID. On the right under Value select the field to pass the value, ex: #P1_ID# and click ok. Now, when the link on page 1 report is clicked, the P1_ID is saved into Session state by Apex and passed to P2 which then performs a FETCH using the passed value. You can read more about Session State here. Also, be aware there are security settings which affect what params can and can't be passed in the URL. Clicking "Session" in the developer toolbar will enable you to see the session variables being passed.

If you mean "How do I store values in the app that can be accessed anywhere in the app - like a global variable" Then look at Application Items.

As always, please include version numbers in these posts.

1
votes

When you create a target page let's say Page 3 And you create some items, let's say P3_ITEM_1,P3_ITEM_2, etc

You can assign values to each of them through the url in the original page

The complete APEX URL Syntax looks like this:

http://apex.oracle.com/pls/apex/f?p=AppId:PageId:Session:Request:Debug:ClearCache:Params:ParamValues:PrinterFriendly

Let’s take a closer look:

  • http:// – the protocol, can be http or https apex.oracle.com – your domain/host/server, whatever you want to call it. Can also be localhost.
  • /pls – indicates that you are using Oracle HTTP Server with mod_plsql. If you are using APEX Listener or Embedded PL/SQL Gateway this part is obsolete/missing.
  • /apex – the entry from your dads.conf file (this a file on your application-server or EPG where the target database is configured) – in case of EPG its just one entry pointing to localhost, in case of an OAS you can have multiple entries, each pointing to an other database
  • /f?p= – procedure “f” is called and parameter “p” is set to the complete rest of the string. Remember: APEX uses mod_plsql. “f” is a public procedure, this is the main entrypoint for APEX. Or you could say: “f” is APEX.
  • AppId – the number or the Alias of the Application
  • :PageId – the number or the Alias of the Page
  • :Session – unique Session ID, can be 0 for Public Pages or empty (then APEX creates a new Session)
  • :Request – a Request Keyword. This is basically free text, just a string you can specify to react in a process or region condition on. e.g. you could pass the keyword “CREATE” and have a condition on the delete button of your page saying “dont’t display this button if request is CREATE”. In other words: use the REQUEST to control the behaviour of your page. When pressing a button, the button sets the REQUEST to the button-value (e.g. SAVE), so that you can control the processes in the page processing (Submit) phase.
  • :Debug – set to YES (uppercase!) switches on the Debug-Mode which renders debug-messages and timestamps in your Browser window. This helps to detect wrong behaviour of your page or performance issues and everything else. Every other value then YES turns the Debug-Mode off
  • :ClearCache – you can put a page id or a list of page ids here (comma-separated) to clear the cache for these pages (set session state to null, …). But there is more: RP resets the pagination of reports on the page(s), a collection name deletes the collection, APP clears all pages and application-items, SESSION does the same as APP but for all applications the session-id has been used in.
  • :Parameters – comma seperated list of page-item names. Good practice is to set only those page-items which are on the page you are going to. Accepts page-items as well as application-items.
  • :ParamValues – comma separated list of values. Each value is assigned to the corresponding Parameter provided in ParamNameList (first value assigned to first parameter, second value assigned to second parameter, and so on…). The trick here is not having values which contain either a comma “,” or a colon “:”. Both would lead to side-effects and errors, as APEX gets confused when parsing the URL. Using a comma works, if enclosed by slashes: e.g. \123,89.
  • :PrinterFriendly – set to YES (uppercase!) switches the page into PrinterFriendly-Mode, uses the Printerfriendly template to render the Page. You can also hide regions or other elements in PrinterFriendly-Mode using the PRINTER_FRIENDLY variable in a condition.

In your case you'd use Params:ParamValues like this:

P3_ITEM_1,P3_ITEM_2:someValue_1,someValue_2

Documentation