— Simon Greenwood (@APEXORADEV) December 7, 2016
It describes some goals for APEX 5.2 and beyond, of course coming with the usual safe harbor statement - we're still waiting for 5.1!
I do enjoy these snippets into the future, having talked about various APEX SOD in the past. Though I realise I'm doing this not having heard the talk that came with the slide, so I could be interpreting things wrong.
This was the best image I saw, so for those who struggle to read it (emphasis theirs):
- Tighter integration / native integration with RESTful web services and ORDS
- Improved integration with Developer Cloud Service (hudson, git)
- Enhanced self service cloud with documented RESTful APIs
- Proper APEX app diff, full app change history capture
- Friendly URLs
- Automated APEX app testing
- Greater internal use of JSON expanding on interactive grids and page designer
- Allow page designer to set IR and IG report settings at design time
- Multiple concurrent versions, for example 5.1 and 5.2 - goal is to ease upgrade
- Documented APIs to dynamically generate APEX application components
#4 will excite the bean counters, though I'd be happy with just a more accurate change history.
#5 A zillion ways to do this, but something within the builder would be cool. Particularly since I've attempted none of them.
#6 well, this would be impressive.
#8 excites me, particular in a world where half the time I don't include the search bar, so modifying report settings becomes a pain.
#9 surprises me. I'm not sure how they'll solve this, but quite an engineering effort when upgrades are fairly seemless, the UT has the Verify option that we'll finally be able to play with, and we also have jQuery legacy options in the UI details. But I guess it does reduce the need for another server during regression testing...
#10 still not sure I get why people want to do this, but why not I guess.
Noticely absent: any mention of OracleJET. I thought they may take fuller advantage of such a rich product.
To me this list is another sign of APEX's maturity. 5.0 came with a lot of stuff to excite developers, and 5.1 ties a tidy knot in the bow (and introduces OracleJET...)
This list for 5.2 is mostly infrastructure stuff, right?
Time will tell.
10 comments:
#10 I do this a lot.
One of my concerns is that its not really "supported" so the apis can change with each release.
What's your basic use case? I think the closest I've got is just defining stuff on the fly with htf package.
My basic use case is that I want to only do a step once, then script it to repeat it as often as I need it. For example, applying a standard set of attributes to all pages, regions, items, etc.
The other use case is to make my own custom version of the "new page" or "new app" wizard - e.g. generate a report and edit page for a set of tables, but set up regions, items and buttons how I want them.
My use case is for application maintenance and page creation.
I have 150-200 pages in my MI application. I generate these pages based on values stored in a series of simple metadata tables. All page creation is done using the APIs looking at my metadata tables. This ensures that the generated pages all have correct and consistent settings (so as not to confuse the end users) including security attributes, format masks, primary and alternative reports groupings/charts.
If the underlying report query (i.e. database view definition) of any report needs to be modified, the apex page will also need to reflect the change so I use my auto-builder to regenerate the page in a matter of seconds. Similarly if I want to add a new setting to any or all of the pages, the API will perform all the changes in a minute or so - after all who wants to go through each of 200 pages to modify just one interactive report setting on each page, where's the fun in that?
#10: We talked about at the Podcast at APEX Connect 16 with Mike. And all the above should be addressed. Create pages automatically for thousands of Form migrations. Modifying all your pages with standard settings.
#9: Is a big thing. It's always a nightmare to upgrade to new versions in companies. They often have hundreds of Apps running on one instance. Good luck to agree with 50 project manager to do an upgrade forcing all of them to retest their Apps :-)
I agree with the infrastructure approach. BUT if the REST Service integration will really work ( e. g. a Interactive Report based on a Webservice ). Then APEX will become some kind of an "Application Server" ready to work with all data from all databases and other sources as well. I would consider this as the biggest step for APEX ever.
@Jeff I would like to be able to do that via the builder, though I see how APIs would be hust as handy.
Your second case sounds like a pretty cool macro!
@Kathryn there are tools already to help identify inconsistencies, but I'm not sure you *need* APIs to make this happen.
I admit, I've had a similar need.
@Juergen Good point about #9 and hundreds of apps. Another method for phasing migration.
Its not to identify inconsistencies Scott, its to build new or rebuild several (many) or just one apex pages at the click of a button.
Sounds like data driven application development to the extreme!
expecting #2 & #5
Working with APEX 5.1, my wishlist so far would be to enable/disable user features at design time for IG as can be done with IR (for example disable the Chart action) and finish integrating various Oracle JET charting options (for example Gantt). IG with edit enabled also seems to have an issue with text areas too (row action no longer aligns vertically with multi-line text).
Post a Comment