As a way of welcoming Michael Lucas Smith to Portland, we asked him to present this month at the Portland Smalltalk User’s Group and he agreed to talk about WebVelocity. (Michael is the lead engineer for WebVelocity with Cincom Smalltalk.) These notes were taken during the presentation:

Michael started with a history of the various dialects that are part of Cincom Smalltalk. He showed us some code in VisualWorks that dates back to the original Smalltalk-80:
Cursor earth showWhile: [(Delay forSeconds: 5) wait].

WebVelocity is a server-based system that has all the tools in the web browser. This is the ultimate “eat-your-own-dogfood” situation where all the tools are themselves using Seaside. For persistence, WebVelocity uses “ActiveRecord” and ActiveRecord uses GLORP, so if ActiveRecord is not sufficient you can dive down to GLORP which has almost unlimited flexibility.

Much of the goal of WebVelocity is to reduce the barrier to entry by making Smalltalk more approachable. Thus, there are a number of things that will not be as familiar to those coming from other Smalltalk tools, including VW.

Given the prevalence of relational databases, the focus is on making back-end persistence easy. Creating an application starts with a default setup, including connection to the database of your choice. We could define the database, or use an existing database. From the web browser, we go in and use the database schema to create classes. The tools create up to seven classes for each table, including domain model, multiple testing classes, and user interface components.

The classes are created with appropriate instance variables (as selected through the web browser). Once the classes are defined, the web components are already there, and we can “run” the application “scafolding” (similar to the Rails term), except that instead of templates you get abstract superclasses that provide lists, editors, etc. If, instead of looking at an ‘html’ page, we request a ‘atom’ page, we get an XML object. We can also get XML and JSON directly from the scafolding.

The example had a customer and a product table joined. Michael showed an example of adding a #printOn: method. Going to the web browser for the class, there is a list of method categories and the #printOn: method was offered by default. Methods added and edited are saved automatically. You don’t need to save. In fact, you can edit multiple methods at a time. You can even walk away from methods with compile errors and the tools help you come back to them.

The tools provide undo and redo as a way to avoid any problems from automatic saving. There is extensive use of “tool tips” that show errors as you are typing. There is a built-in “help” system that has extensive documentation provided as part of the web user interface. The documentation drills down to the method descriptions.

Michael added a method with an error to demonstrate the debugger. While the point is to demonstrate the web-based debugger, it turns out that in his image he had been using a different debugger (the one in the Smalltalk image). He was able to quickly switch a preferences to use the web debugger and then go to the web browser. He was able to edit, save, and continue.

There is a “Console” that is available from most tool windows. In the console, you can type an expression in the text entry field at the bottom of the window and the result of the expression is added to a list in the main section of the window. The main section contains a list of tree views, so you can inspect the resulting object. This seems like an elegant alternative to the traditional Smalltalk workspace. It is more like a shell where you type an expression and the result is added above the line.

Source code is generally managed with Store, but the WebVelocity tools provide a new view on Store as well. Store is quite powerful and provides a distributed code repository environment.

What comes next? It still needs a lot of documentation. Also, since it is aimed at developers new to Smalltalk, it needs to be fairly complete and easy to use.

There has been a lot of UI design and learning, and yet most Smalltalk browsers look mostly the way the did 25 years ago–with added toolbars and coloring, but not a fundamental change in the approach. With WebVelocity the design started over from scratch, and asked how tools could be built to be useful to a developer.

Comparing ActiveRecord to GLORP: If you had a link table that you want to treat as a Dictionary (rather than a third table), GLORP can be configured to populate a dictionary. GLORP provides the way to create a database schema with multiple tables having pre-defined relationships. You can defined classes, and then define how the tables are mapped to the classes.

In many situations, rather than just a blank method, you get a method template with a number of commented-out lines that give examples of the sort of things you are likely to want. For example, the table definition gives examples of various types of columns that can be added.

Interestingly, in the code browser where you write Smalltalk methods, you can also create CSS and JavaScript. The system recognizes that the thing being typed looks like something other than Smalltalk.

In a way, Cincom has been a victim of its own success–particularly with regard to downloads of marketing and education material. Of course, this problem is being addressed, and it is a great problem to have!

If you want to get involved in the beta program, email jarober at gmail dot com.

After the WebVelocity discussion, Michael showed us some of his work on OpenGL. It seems that the API has changed significantly, and he is building some lessons that demonstrate usage of the new API. I think this would be a good subject of another meeting!