I don't have an answer to your problem really. I tried something similar before, but couldn't exactly work it out (yet).
or there is some better approach?I do have a suggestion (maybe not better, though). Instead of the form region, create a tabular form region and just fetch one row. This type of region can use partial page refresh when the LOV is changed. Here is an example with a tree, but this can be changed to an LOV instead.
The "On Demand" AJAX call appears to be failing because it expects the PROCESS_SOURCE of an Automated Row Fetch process to contain PL/SQL code and not whatever this is:
The above PROCESS_SOURCE can be found in the tree view of Page 10 by hovering the FORM_FETCH AJAX Process or by running the following query:
SELECT * FROM apex_application_page_proc WHERE process_point_code = 'ON_DEMAND' AND process_type_code = 'DML_FETCH_ROW';
It'd be nice if someone could fix this... or if the code for interpreting the above ARF PROCESS_SOURCE could be exposed so that we can create an PL/SQL AJAX On Demand process that does the same thing without failing.
The ARF simply doesn't work this way. Calling it on demand would never set the values of items on the client side. It sets the session state of the items during the render process, but that state is not retained. So even if you did run it through ondemand and it would work, you'd have nothing.
Aside from that, why are you trying to do this? When I read your page setup I take it to be a master-detail form, where the master has a select list. Selecting something from the select list will show the master record data. Why not just use a submit/redirect to have the page rendered with what you need?
It's a bit painful to have to switch between pages all the time. It'd be nice if pages were more responsive in APEX.
- Take an Interactive Report
- Click "Edit" in one of the rows to show a region that allows you to edit that row.
- Click edit and convert the row into a bunch of form fields.
So ARF is the wrong tool for the job and should just be reserved for basic point-and-click pages...
Having said that, I believe there are plenty of options of making apex pages more responsive, but of course it will always depend on requirements and the datamodel and architecture.
You mention the edit of an IR row in a region. I have implemted this several times over now by using the modal page plugin. It is easy to implement, looks good, avoids the page switch, and allows you to leverage the apex architecture.
As for that multirow editing, maybe in apex 5.0.
Bascially though, you can make apex as responsive as you want, if by responsive you mean plenty of ajax. Just not so much out of the box. It'll cost you time and requires a good deal of skills in all technologies involved in my opinion. That's why I'd recommend to think twice about a solution or route you want to go down to. Don't try to break the mould where it makes no sense etc. I understand the concern, but then again that's just how it is at the moment. Be creative in your solutions, but don't push it unless you need/want to.
No critique, just saying.
I'm trying to stick with standard APEX features so that it's easier to support if/when other developers build upon the existing application. On the other hand, I don't want to compromise usability.
I appreciate your input and feedback.
I'll write a page process to return JSON for the form to use after clicking "Edit" and I'll get the users to decide between a modal popup and displaying a form above the IR.