On apex.oracle.com I created an example of an updateable Interactive Report. It is not an in-line update functionality, but you can click on an image and so update the status of a record. It is not rocket science but a nice way to present such a functionality to your end users.
But while creating the example I discovered that the example worked on a Page that requires Authentication, but didn't work on an Public Page... To call the On Demand Process I used the namespaced function apex.ajax.ondemand, instead of the more or less old-fashioned htmldb_Get. But unlike the htmldb_Get, apex.ajax.ondemand has no parameter for the page where the process should run (actually apex.ajax.ondemand passes '0' as the page parameter to htmldb_Get). So in order to get things working I needed to mark Page 0 as Public also...
I guess it would be a nice enhancement if you could either pass a page parameter to apex.ajax.ondemand (default 0 is acceptable) or it should use the current page ($v('pFlowStepId')) as a default. Then you don't need to mark Page 0 as Public also. And I want as less Public Pages as necessary...
But while creating the example I discovered that the example worked on a Page that requires Authentication, but didn't work on an Public Page... To call the On Demand Process I used the namespaced function apex.ajax.ondemand, instead of the more or less old-fashioned htmldb_Get. But unlike the htmldb_Get, apex.ajax.ondemand has no parameter for the page where the process should run (actually apex.ajax.ondemand passes '0' as the page parameter to htmldb_Get). So in order to get things working I needed to mark Page 0 as Public also...
I guess it would be a nice enhancement if you could either pass a page parameter to apex.ajax.ondemand (default 0 is acceptable) or it should use the current page ($v('pFlowStepId')) as a default. Then you don't need to mark Page 0 as Public also. And I want as less Public Pages as necessary...
Comments
I agree, it makes sense to be able to specify the page for the namespaced version as well. We will look into this.
Anthony.
And looking at the code it seems not so difficult to make that adjustment.
Cheers,
Roel
I think it would make sense to always use "current page" instead of page 0 as Roel suggested. An extra parameter for the page would only make sense if page level on-demand processes are supported in the future and a developer wants to call an on-demand process of another page.
Cheers
Patrick
Ok, I think that a combination of the 2 would make sense, so we default to the "current page", but still provide an optional parameter for the page for the situation Patrick mentioned, (as we are currently looking at page level on-demands) and also where the developer wants to leverage other components (such as regions) defined on different pages.
Anthony.