- As Trent Schafer (@trentschafer) noted in his latest blog post, "Reset an Interactive Report (IR)", there have been numerous customer discussions and blog posts which show how to directly use the gReport JavaScript object to manipulate an Interactive Report. The problem? With the massive rewrite to support multiple Interactive Reports in Oracle Application Express 5, gReport no longer exists. And as Trent astutely points out, gReport isn't documented. And that's the cautionary tale here - if it's not documented, it's not considered supported or available for use and is subject to change, effectively without notice. While I appreciate the inventiveness of others to do amazing things in their applications, and share that knowledge with the Oracle APEX community, you must be cautious in what you adopt.
- In the rewrite of Interactive Reports, the IR component was completely revamped from top to bottom. The markup used for IRs in APEX 5 is dramatically improved: less tables, much smaller and more efficient markup, better accessibility, etc. However, if you've also followed this blog post from Shakeeb Rahman (@shakeeb) from 2010, and directly overrode the CSS classes used in Interactive Reports, that will no longer work in IRs in APEX 5. Your custom styling by using these classes will not have any effect.
- As the Oracle Application Express 5 Beta documentation enumerates, there is a modest list of deprecated features and a very small list of features which are no longer supported. "Deprecated" means "will still work in APEX 5, but will go away in a future release of APEX, most likely the next major release of APEX". In some cases, like the deprecated page attributes for example, if you have existing applications that use these attributes, they will still function as in earlier releases of APEX, but you won't have the ability to set it for new pages. Personally, I'm most eager to get rid of all uses of APEX_PLSQL_JOB - customers should use SYS.DBMS_SCHEDULER - it's far richer in functionality.
Please understand that we have carefully considered all of these decisions - even labored for days, in some cases. And while some of these changes could be disruptive for existing customers, especially if you've used something that is internal and not documented, we would rather have the APEX Community be made aware of these changes up front, rather than be silent about it and hope for the best.
10 comments:
I greatly appreciate the heads up. This will unfortunately affect more than I'd like to admit as I am one of the gReport abusers. I just went through one of my apps to remove these references. I first created a dynamic action on the IR region that used a custom event to refresh the region. Then, in my JS instead of calling gReport I used $.event.trigger('DynamicActionName');
This seems to work and the functionality from the end users point of view is the same. But the question is, how stable is this approach?
Hi Tony,
Great that you are already addressing this in your apps already.
I think the right solution depends on exactly what you're doing in your app and code. Is this something that you could handle in a Dynamic Action alone, without needing to trigger the custom event from some external JS? I think that would be preferable, if possible. What does the JS do? If you really need to handle this external to DA's, I would suggest to bypass the DA framework and just refresh the region directly, by triggering the 'apexrefresh' event on the IR. Is that documented I hear you say!?! Well, in 4.2 I have to say it isn't, but that was an oversight on our behalf. It should have been, we use it extensively in our hosted plug-in code for example. I have filed documentation bug #20516679 to address this omission, which we definitely plan to fix for 5.0.
So, to use 'apexrefresh', you should do the following:
apex.event.trigger( "#myRegionStaticID", "apexrefresh" );
This will be the recommended and documented approach to refreshing APEX components from JavaScript going forwards. But again, I would still suggest to stick with pure DA's if at all possible, depending on what you are doing prior to the refresh.
Regards,
Anthony (APEX Team).
Hey Anthony -
Thanks for the follow-up. In most cases I am altering the data within the report in some way. Sometime I am adding a record via an Ajax call and then refreshing the IR and in others I have a status column within the IR that I allow users to click and toggle that status on/off, again through an ajax call. So I'm already in JS to make the apex.server.process call so making a call to the apex.event.trigger makes a lot of sense and it is easier to implement than creating the extra DA on each IR region. So I appreciate that.
Speaking of JavaScript APIa, right now the apex.server.process includes {Success:}, but I think that is no longer part of the JQuery ajax call, is this going to be supported in 5.0 still, or will we need to recode our ajax calls to use done?
I have a request to change the background color of some specific columns. I used to add a css class that will find the columns by headers, like td[headers="MY_COLUMN"].
But in APEX 5 the headers became something like this headers="C29198331736292823348". Is there a way to get the headers back?
Hi Tony,
Thanks for the info. I hear what you're saying, the 'apexrefresh' approach will work fine for you, and I can see how this would represent the path of least resistance for 5.0 readiness, although again 'pure' DAs would be my recommendation for future development, if possible.
About jQuery Ajax 'success'. The 'success' callback, where you define a function to fire when a successful Ajax call returns has not been deprecated in the updated version of jQuery used by APEX 5.0 (2.1.3 / 1.11.2), and will continue to work as expected. What's been deprecated (but not yet removed, so will also continue to work), is the 'success' method on the jqXHR object returned by the Ajax function. If you are using this, then this will still work in 5.0, but this should be replaced with 'done', as per the deprecation notice on the jQuery.ajax page:
http://api.jquery.com/jquery.ajax/
But again, this has not been removed, so there is no need to do so for 5.0.
Hope this helps, and thanks again for your feedback.
Regards,
Anthony.
Our Apex is on Oracle DB 11.2 with Oracle HTTP server 11.117, can I upgrade Apex 4.2.6 to Apex 5 in place? In another way, what's the system requirements for Apex 5? thank you.
Hi Sean,
The installation requirements are available in the Beta version of the documentation:
https://docs.oracle.com/cd/E59726_01/install.50/e39144/pre_require.htm#HTMIG376
Joel
Hi Joel/Anthony,
I must admit, when I was reading this entry about gReport, my heart sank a bit as I was thinking, I have $("#REGION_STATIC_ID").trigger( "apexrefresh" ); in quite a bit of my JavaScript code and this is not a documented feature.
Thanks Anthony for clearing this up and going forward I will use apex.event.trigger( "#REGION_STATIC_ID", "apexrefresh").
Cheers,
Paul.
Sean,
Many thanks for your valuable feedback. Just some quick background. As Joel discussed, Interactive Reports underwent extensive change in Application Express 5.0, in order to provide support for multiple on 1 page, and to modernise and clean up the component. The column header markup you highlight was one such area of clean up, and this change was made in support of multiple IR's on a page, where we needed to remove the risk of ID collisions on the page, and was therefore changed to instead use the internal ID of the column, rather than the column name. As you point out, this will have grave consequences for those who have defined either CSS or JavaScript customisations based on the assumption that the column name is used.
Thanks to you, we have now addressed this in development in 5.0. We have introduced a 'Static ID' attribute to the column, which can be set to the column name, and if so will be used instead of the internal ID, just as it was in previous releases. In addition, existing applications that are upgraded to, or imported into an Application Express 5.0 environment will have this Static ID automatically set to the column name.
So to answer your question, you don't need to get them back, we have done it for you! Thanks again for taking the time to bring this up, we really appreciate it.
Regards,
Anthony.
Post a Comment