Now that Oracle APEX 18.1 development is winding down, code freezes are in place, and only bug fixes are being allowed to be addressed, I’ve directed my development efforts in another direction.
The obvious first stop for this was Oracle Jet’s own learning page. From this page I chose to start with the MOOC that the JET team had authored. I dutifully signed up for it, followed it all the way through and learned a good amount about what JET is capable of and how the development environment all hangs together.
It was at this point I started to stretch my wings by attacking a small project assigned to me by Kris Rice – Modernizing a small SQL-Developer Usage Statistics reporting app.
Big Brother is Watching (but only if you let him)
As you are likely aware, SQL-Developer (like many other software products) collects anonymous statistics about how you use it. You’re asked when you first install the software to allow the collection and it can be turned off at any time from the preferences section under Usage Reporting.
SQL Developer occasionally sends that collected information back to Oracle so that we can see how our customers are using the tool.
The data that is collected has to do with what parts of the tool are being used and what flavors of database (and which versions) are being accessed the most.
Reporting on Gathered Statistics
A Noobs Learning Journey
Since I’m new to JET, I thought it would be a good idea to simply replicate exactly what I saw in the D3 app, in JET. This way I could make sure that the graphs looked the same and the numbers I was getting matched. Then I could go about making the changes to slice and dice the data in different ways.
Based on my experience with the MOOC, I really thought I had the grounding to do this without too much problem. After all, there were only 4 objects on the screen; two select lists, a chart and a data table. However after slightly more than a couple of frustrated days, I realized that what I didn’t know about KnockoutJS (a critical part of the JET infrastructure) was clearly “observable”!
The REAL Learning Starts Here
What should have been a 30 minute troubleshooting session where John looked at the code and told me where I was being stupid, turned into a 3 hour debugging session that had us both scratching our heads for quite some time. We tried various things to make what I had done work, but in the long run we discovered that I had just done some things blatantly “wrong”.
Second, I was trying to load my 3rd party library the old school way (by simply including it in the base HTML as a script) instead of using RequireJS to load it.
After going back and fixing those issues, everything started working much more smoothly with no console errors.
Next Steps – Refactoring
As much progress as I’ve made, there are things that need to be addressed even before I start slicing and dicing the data differently. For instance, currently the REST calls are instantiated each time you navigate to a tab. This shouldn’t need to happen as the data does not change that frequently, so I want to refactor the REST calls out so that they’re called once when the application is instantiated and then used by the individual tabs.
Also, because the displays on each tab depend on the fact that the application can reach the REST services, I’d like to disable the tabs until I know the REST data has been returned correctly and is ready to display.
I’d also want to give the user the opportunity to force a refresh of the individual data models. This would mean disabling the tab, re-executing the REST call and then re-enabling when ready.
While this sounds straight forward, It involves learning about communication between various data models that are defined in the application. While I’m sure there are structures and methods in place for just that reason, it’s going to be a whole new area of study for me.
Wish me luck and I’ll report back on that in a forthcoming post.