I am trying to create a Dynamic Action Type Plugin. In the Dynamic action plugin, one of the custom attribute is of the type PL/SQL Body returning varchar2 which goes something like this.
DECLARE
query_string varchar2(4000);
Begin
query_string := 'select firstname, lastname from student where id = '|| :PAGE_ITEM_ID;
return query_string;
END;
I found out that when the PAGE_ITEM_ID is updated by any other dynamic action, this dynamic action is still using the old value although the session value is already updated. I think this is because the dynamic action is rendered during the page load and hence uses the value at the time of page load.
Is there a way around this so that the above dynamic action uses the updated value?
You need to use the "Page items to submit" property to send information from the browser to the database (and "page items to return" to send updated session state values back to the browser)
But I'm not sure how this differs in the world of plugins, in your specific context.
Related
There is a problem transferring values between pages in the application. I have 2 pages on the first page there is a variable P9_ITEMID (when you run page 9, in this variable SQL Statement query writes the data). There is a second page 181. I want to move data from variable P9_ITEMID to variable P181_ITEM. To do this, I use the 'redirect to page in this application' option. But it doesn't work. Although I see in the variable P9_ITEMID there is data. But when you go to page 181 but P181_ITEM is empty. I would be grateful for help))
P9_ITEMID is a virtual variable that is not assigned to any column in the table. This mmin simply displays data. When I start the page, I see the data that was written to it due to the dynamic action
also i tried to write the value in P9 ITEMID this way
My code:
declare
v_empname items.id%type;
begin
select id into v_empname
from items where id = :P9_ITEMID;
apex_util.set_session_state('P9_ITEM_ID', v_empname);
exception
when others then
apex_util.set_session_state('P9_ITEM_ID', null);
end;
I'm assuming that you have created a button with action: 'redirect to page in this application' and you want the session value of a page item to be passed to the target page.
When an url is constructed using link builder, the link is built at page rendering time. It does not pick up any changes in session. Even when you set the session state in a dynamic action, it will not pick it up because the url is already rendered.
To pick up any changes on that page, it is necessary that the page item value is set in session state and this is done by the "page processing".So if you use "Submit Page" on the button and create a branch to redirect to the page it will behave the way you want.
when you AutoREST-Enable a table through object browser> click table> REST tab, you will get a RESTful URI. If you then build a web source using that RESTful URI, you will get five operations - GET with a dot as URL pattern and GET, PUT, POST and DELETE operations with URL pattern has the value of :deptno. When you build a report with form on that web source you will find that all database operations work well, you can insert, update and delete through the form, and you can run the report to get all rows in the table. I need to know how the process work in the background? How the automatic row processing process knows which operation and handler to use? I know that Interactive Reports for example looks for the operation that have "Fetch Rows" it's database operation. So, I assumed that the Form's automatic row processing looks up for the Web source's operation with the database operation that relates to the process to be executed. For example, (correct me if I'm wrong) when clicking CREATE button, it denotes that an Insert process will happen, so, it will search for the web source's operation with the database operation "insert row", then it will find the handler that relates to the HTTP method attribute's value "POST". And the same goes for UPDATE and DELETE. I want to know if I am getting it right and I need to know how the URL Pattern gets it's argument for :deptno?
your understanding of the form region picking the Web Source Operation is correct. Within the Form Region, the name of the clicked button (:REQUEST) actually determines the DML operation (CREATE = Insert, SAVE = Update, DELETE = delete).
A :deptno URL parameter must also be created within the Parameters section of the REST data source. Once that is in place, you'll see the form region node in the Page Designer Tree having a Parameters node - there you can map the Web Source Module parameter to a page item, an application item or something else.
As already mentioned, the primary key values are special in a Web Source Module. In your case, the :deptno placeholder (as part of the URL) corresponds to the DEPTNO data profile column.
For the DML handlers (PUT, POST, DELETE) you don't need to define these as Web Source Module parameters, but the URL placeholders must match the column names in the data profile. This is by design - Web Source Modules are implemented to work this way.
I don't see the values in Session when using the Debug, but the page items are rendering:
I am setting the Source using a SQL Expression:
And I know the query is working, as the page item is rendering out for P2_KPI_NAME on the page.
Why are they not being added to Session once calculated?
The fact that you see it doesn't mean it is in session state.
For testing purposes, create a button on that page which will perform SUBMIT. Push it, and then check Session tab in Debug output.
You could use a dynamic action on change of :P2_KPI_ID in which you set your second item using PL/SQL (remember to add P2_KPI_ID to Item to Submit aswell as your second item as a Item to Return).
"Always replace value in Session State" sets the items value when its getting rendered.The item itself is not refreshed when your :P2_KPI_ID is set and therefor its value is not set automatically.
You're seeing the result of a performance optimization used during page rendering. Most of the time we think of session state, we think of persisted session state, i.e. the state in the session table.
However, in-memory session state is often used by APEX when rendering a page to avoid the overhead of running DML against the session table when it usually doesn't need to be there anyway (the next submit will overwrite it).
See this old, but still relevant, post to learn more:
http://c2anton.blogspot.com/2008/12/oracle-application-express-apex-three.html
I am attempting to call an APEX process from a dynamic action. i was able to do that via Execute Javascript code action, by using
apex.submit({request:'PROCESS NAME HERE'})
But I was wondering if there is a better way to do that, such as an APEX action
First to say (just to be clear) what you've written in your code as 'PROCESS NAME HERE' is not a process name (as those words might suggest) but a request value, as can be seen from your code.
You can do the very same thing using built-in APEX action:
Choose Submit Page as your Action
Enter your request value (aka the string you clouded with 'PROCESS NAME HERE') under the Request / Button Name field
Under the process you want executed set Server-side Condition as follows:
Type: Request = Value
Value: your request value (aka the string you clouded with 'PROCESS NAME HERE')
If you have other processes on your page as well that you don't want during this page submit, then you must do some of the following:
set their Server-side Condition to exclude that request (this is the easiest way if that process doesn't have any Server-side Condition defined yet): Type: Request != Value , Value: your process value
add that process value to excluding list for that process (either add it to the Value while using Request is NOT contained in Value type or change your Request != Value type into Request is NOT contained in Value if you've been excluding only one request before this)
I hope that helped and answered your question.
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?
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.
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