Rapid Web Application Development with AppeX and the Chrome Development Tools
Part I. Motivation for the AppeX JSFile Externalization Framework
This short article serves a dual purpose. On one hand, it is an introduction to AppeX’s “JSFile” framework, which will be available in Cincom® VisualWorks® 8.2, and on the other hand, it is an exploration of the motivation behind the JSFile framework. In addition, it serves as a lead-in to a second article titled, “Using JSFiles in Conjunction with the Chrome Development Tools.”
The goal of AppeX is to ease development of web applications. To aid in this goal, AppeX uses the strategy of keeping in step with the latest in web application development technologies, and the not unrelated strategy of “playing well with others.” The JSFile framework is one component of the strategy of fitting naturally into the broader web development ecosystem.
This pair of papers illustrates the point by considering a RAD development style that AppeX can support primarily because of its underlying design.
Many software application developers (and most especially Smalltalkers) have grown accustomed to a particular style of exploratory coding and development that is sometimes known as “coding in the debugger.” Conceptually, this development process is very simple:
- Write “exploratory code” while fleshing out a skeleton application, halting code execution at any problem points, modifying the code in place in the debugger and then continuing on with code execution.
- Repeat (A) until the application functions correctly.
Instead, web application development has historically followed a much more cumbersome process.
Here is a typical web application development process:
- Re-run the program and observe any new problems that arise.
- Return to (A); that is, return to the tools, re-edit the files and code, re-run the program, observe the results and so on.
The main development pain points that these fairly typical web development steps introduce, as opposed to the “coding in the debugger” (that, incidentally, can be routinely performed in many non-web environments), are a large number of context and tool switches and slow iterations of making changes and testing those changes.
It is too large of a claim to make that AppeX enables exactly the equivalent of “coding in the debugger” as would be available in, for instance, a non-web Smalltalk development environment. However, what can be said is that AppeX and JSFile is a step in that direction. The next article illustrates a simple example of “coding in the debugger” with AppeX and Chrome workspaces.
For the following examples to work, you will need to install a recent VW8.2 pre-release build. If you are a Cincom Smalltalk™ licensed customer, please subscribe to the CST Developer Program to gain access to the most up-to-date code.
- open VW System Settings’ and navigate to the Web Development item.
Alternatively, one can execute in a workspace:
Application codeComposer: JSFileComposer
The default script directory in which AppeX will place the JSFiles is
…image/appex/scripts, e.g. C:/vw8.2/image/appex/scripts
(on OSX, this would be /Users/<yourUserId>/vw8.2/image/appex/scripts)
The directory can be changed in VW Settings>Web Development->Script Subdirectory or by executing, for instance,
Application class>>scriptDirectory: ‘myJSFiles’.
This first step activates a JSFileMonitor daemon in AppeX that will monitor the selected directory for changes to be parsed and imported into AppeX.
Again, this directory is by default … image/appex/scripts.
The instructions given on the website for adding the directory are included here for convenience:
“To make a local folder’s source files editable in the Sources panel,
Right-click in the left panel of Sources and select Add Folder to Workspace.
This launches you into a file dialog where you can choose a new folder to add to your Workspaces. ”
You will see a message in the Chrome Debugger saying “DevTools requests full access” to the directory.
You can now edit any of the source files in that folder or its subfolders in Chrome.
For instance, “AppeX.CoreCode.js” might map to the resource “localhost:8889/appex-counter/AppeX.CoreCode.js”.
After mappings have been established, we’re ready to do some coding!
Let’s set breakpoints in the chrome debugger and change the code when halted at them.
When you refresh your browser, those changes will be reflected both in the browser and imported in the AppeX environment.
Conversely, any changes made within the AppeX IDE will be written out to the file system and will be reflected in the Chrome browser upon browser refresh.
Open the Chrome DevTools JS search box with Ctr-Sh-F (Cmd-F on OSX). Search for “Decrement”.
Inside the callback function to the “click” event of the decrementButton, click to place a breakpoint beside “self.decreaseCounter();”
Back on the Counter application display, click the button labeled “Decrement”.
The debugger should halt at the breakpoint.
Duplicate the line “self.decreaseCounter();” in the debugger, and save your changes with Ctr-S.
Resume execution, and try pressing the decreaseCounter button on the web page. The Counter should decrease twice with each button press.
So far so good, but so far, we’ve seen nothing beyond what Chrome devTools workspace provides without AppeX.
Now refresh the Counter screen, and try pressing the button again. Still good, but still nothing exceptional.
In the same Smalltalk pane, change
label: “Decrement” to label “Decrementing”, and save your changes.
Now, when you refresh your Counter application in the web browser, it will show the new label.
t’s change the label again, but this time from the Web browser.
Return to the previous search in Chrome devTools.
Change the line
and ctr-s to save.
Refresh your browser to see the change.
You verify that the change made in the web browser propagated through the filesystem and Smalltalk IDE by again looking at the CounterClient>>buildToolBar method.
Final Notes and Cleanup
If you want to remove external JS files and the changes they contain, you can either do so through OS tools or have the AppeX do it for you automatically by selecting the box “Delete script files when switching to Image methods”.
Alternatively, execute the following in a workspace:
This has been a bare-bones illustration of the capabilities that AppeX and JSFiles provide. The approach described in this article fits well into the future of rapid web application development, and with it, AppeX provides the means to integrate client and server debugging into a single, seamless development workflow.