APEX 5.0 Page Designer: Meet the Widgets

One of the primary things I worked on for APEX 5.0 is Page Designer. There have been a number of presentations and blog posts about what it is, how to use it, and how it increases productivity. What I want to talk about here is what Page Designer is made of. Page Designer was a huge undertaking and a number of people had their hands in it. I’ll focus on the parts I know best; the widgets.

If you are asking yourself, “Could my APEX application have pages as complex as Page Designer?”, the answer is Yes. The level of effort and skill needed is going to depend on what you are trying to achieve. The point is that Page Designer is not taking advantage of hidden or private APEX engine features. This doesn’t mean that all the building blocks of Page Designer are available for use in your applications but that the facilities are there for you to create and integrate your own building blocks. Knowing a little about the architecture of Page Designer may inspire you to create complex, highly dynamic and interactive pages in your applications.

Continue reading APEX 5.0 Page Designer: Meet the Widgets

APEX and Asynchronous Ajax

I rarely read the release notes because I’m in a hurry to get to the good stuff. APEX 5.0 has plenty of good stuff to get to but I want to call your attention to one release note in particular: “Deprecated Synchronous Ajax in Dynamic Actions”

Earlier this year there was an interesting thread on the APEX forums titled Synchronous requests deprecated. It points out that some browsers are now giving warnings (if you have the console open) when synchronous ajax requests are made and, more importantly, that APEX apps that use dynamic actions with Wait For Result set to Yes will make a synchronous request.
Continue reading APEX and Asynchronous Ajax

APEX 5.0 Icon List widget

[As of this writing, APEX 5.0 is only available as a pre-production version installed on apex.oracle.com and might change until it gets released.]

There are so many new things in APEX 5.0 that it is difficult to decide where to start. So, for no particular reason, I’ll start with the icon list widget, which is something that I worked on. The first place you will most likely run into the icon list widget is in Page Designer. Edit any page and at the bottom of the Grid Layout tab you will see a gallery of Regions, Items, and Buttons. At first glance it looks like an ordinary list of images somewhat like the Badge or Cards list templates in Universal Theme. But there are important behavioral differences mainly around accessibility.
Continue reading APEX 5.0 Icon List widget

StringTemplate for JavaScript

About three weeks ago I announced on the StringTemplate discussion forum that I had updated my StringTemplate Standalone Tool (STST) to work with StringTemplate version 4. It has been a number of years since I have used StringTempalte and almost as many since I’ve programmed in Java. So why this return to StringTemplate and Java? My motivation for updating STST is that I intend to create a pure JavaScript implementation of StringTemplate.

So far my work with JavaScript has mostly been creating UI widgets as part of existing web apps and frameworks. I have not had a need for templates, at least not ones processed by JavaScript. That may change with my Climbing Comp project and some other code generation projects I have in mind.

What I’m looking for in a JavaScript template engine:

  • Strong separation of presentation and logic
  • Compiled templates, good performance
  • Mostly need to run on the server using node.js but running in the browser is a plus
  • Can generate any text format, not just HTML

The best match I found is Handlebars. It compiles to JavaScript, runs in the browser and node.js environments, and does a decent job of keeping logic out of the templates. It seems focused on HTML generation but I think it could work for other text formats. I have only played with it a little. There are a few things that I don’t like. Having to write helpers in JavaScript and the way partials are handled distinct from templates doesn’t seem as nice as StringTemplate. Handlebars doesn’t have the separate renderer and writer layers that StringTemplate has. I didn’t do a detailed analysis of the differences between Handlebars and StringTemplate. My gut tells me that I would prefer StringTemplate.

Because, at least initially, I plan to do generation off-line on the server side I could use the Java version of StringTemplate but I would prefer not to add Java to the tool chain; so far I have been able to do everything I need with node. This is what has brought me to creating StringTemplate for JavaScript.

StringTemplate for JavaScript (StringTemplatet-js) will compile templates to JavaScript. It will not have an interpreter. It should be 100% compatible with StringTemplate v4 template syntax and semantics. The API will be different.

To implement StringTemplate-js will require parsing template files and generating JavaScript code. The former would be a good job for ANTLR and the later well suited to StringTemplate. ANTLR can generate JavaScript code but again I would rather not have to use Java. This lead me to try two JavaScript parser generators: jison and pegjs.

I tried jison first and it was a failure. Any syntax error in the grammar resulted in a generic exception with no indication of what went wrong or even the line number. I found my errors by selectively commenting out code until the problem line was isolated. The generated code was extremely difficult to understand and debug. Then when I tried examples right out of the documentation that didn’t work I gave up.

Now I’m using pegjs and it is working very well. The error reporting is very good and the parser it generates also has very good error reporting including source line and column. One minor issue is that it stops at the first error. The generated code is not as readable as what ANTLR3 generates but it is reasonable and I have had no problem debugging it. Not having a separate lexer and parser takes some getting used to. It means having to represent white space throughout the grammar because you can’t just toss the tokens out in the lexer. Some of the things I thought would be difficult, such as having configurable start and stop template delimiters, turned out to be quite easy to deal with.

StringTemplate-js will use itself to generate the compiled template JavaScript code. This is where STST comes in. I plan to use it to bootstrap the process. It will also come in handy in validating that StringTemplate-js gets the same answer as the Java reference implementation.

Hopefully soon JavaScript will have another template engine option. Watch this space.

Scoring Rock Climbing Competitions

The last two years or so I have been very busy working on APEX 5.0. This is the main reason for not posting anything in so long. It’s not that I was so busy with work that I did nothing else, but just that I didn’t have the motivation to write. I should have plenty to write about APEX soon. But this post is about another interest of mine; rock climbing.

My youngest daughter climbs competitively and I try to climb at least twice a week when I bring her to team practice. The local climbing comps consist of proud parents watching their kids climb the hardest routes they can and then, when the scorecards are turned in, waiting around for an hour or more while the scores are tallied. It is not uncommon for people to leave, get lunch, and return before results are announced. In our area, climbing comps typically have 100 or so competitors.

In early 2014 a climbing friend, Matt, who was also responsible for scoring an upcoming competition had some ideas for how to make the scoring go faster. He asked me what it would take to create an app to do scorecard data entry. I saw the project as an opportunity to learn some new technologies I was interested in, specifically node.js, and jQuery Mobile. I picked a mobile web app because it is the best way to reach the widest range of devices with the least effort.

Climbing comps are traditionally scored using an Excel spreadsheet. For each scorecard you look up the row of the climber by name and then enter the number of points for the top 5 climbs and the number of falls (or attempts). The spreadsheet creates a bottleneck because only one person can be doing the data entry. Even if the bottleneck were removed by splitting up the spreadsheet by gender and/or category (or using Google Sheets), the data entry would still be tedious and error prone because of all the numbers that must be typed in. This is why it takes so long to get the results and give out the ribbons so the kids and families can go home and the climbing gym can open for regular business.

I worked a few weekends on the climbing comp mobile web app. I already enjoyed programming in JavaScript and learning node.js was a lot of fun and pretty easy. I chose a thin-server architecture with MariaDB for the database, restify on node.js for the REST resources and static content, and jQuery Mobile for the front end. I specifically wanted to minimize the number of libraries and avoid using a heavy weight MVC framework. This was to reduce the number of new things to learn at once, focus on the things I did want to learn without additional layers, and experience the pain points first hand, so I could better choose what additional libraries or frameworks I might want to add or switch to in the future.

By the time of the first competition, the app was working well enough to be used. The database had to be loaded with climber and route data with command line scripts, but the UI for data entry and reporting results worked. The key point of the app is that the UI closely resembles the score card and it already knows the point value of each route. Data entry is simply a matter of entering the 3 digit climber number from the score card using an on screen keypad, touching each route they topped, and touching the number of falls; 7 taps. The UI is optimized for tablets, but works well on laptops as well, and the UI is responsive so it can even be used on a phone.

On March 15th 2014 we used the climbing comp app for the first time at the Boston Rock Gym. The server and database were running on Matt’s laptop. We had between 3 and 4 people doing data entry on iPad or Android tablets. As scorecards came in, they were divided between the people doing data entry and quickly entered into the app. When time is called, any climbers that are waiting in line get to finish their last climb. By the time the last climber was on the wall, all the other scores had been entered. The owner of the gym had the honor of entering the last scorecard and the scoring was complete before the last climber’s feet touched the ground. The app was a great success. On the down side at least one family, expecting a long wait, left for lunch and returned to find that the ribbons had already been given out.

Since then, the app has been used successfully at two more comps. Before each one I have added new features and fixed bugs. Now climber and route data can be entered or uploaded from the app UI rather than using command line scripts. There is plenty more work to be done but it is just about at a point where others could use it. (Currently, it only works for red point format comps.) ClimbingComp is available on github for anyone to download and use.