The UI of VASmalltalk has always been in discussion since I got to know it around 1998 … one has two ways to build the UI: the original AbtBuilder stuff or the more moderized UI using via WBPro.
I started using VA with the WBPro stuff – the stuff I knew from VisualSmalltalk and loved most.
Over the year I started to hate WBPro – its getting old and the data binding stuff is not up to date any more and then I looked around the AbtBuilder stuff (and its support for data binding up to the UI) – but it was very tight binded to relational databases.
Now 20 years later I find the ideas of AbtBuilder in modern JS frameworks and so many people are getting crazy about these features. I have even seen JS UI building tools, helping building UIs (much smarter looking stuff) with so many ideas already available in VASmalltalk.
Want to have a grid ? Well, assign the content to a domain class and build columns from that domain class in that grid – now bind the grid to a CRUD-storage, make filtering, make sorting available – make paging available. All that was already available 1997 … but never updated to a more general case.
I read today about SQLite extensions and handling them within Pharo. For all VASmalltalker out there … there is an old package from 2013 in vastgoodies, which shows, how to use Smalltalk as an extension in SQLite and how to write functions in VASmalltalk and call them from SQLite … pretty crazy and heavy usage of Callbacks of Smalltalk.
In earlier posting I mentioned, that I enhanced the Gemstone/S database with an event system based on 0MQ. The domain application (written in Gemstone/Smalltalk) are creating events and these are posted on a “pub”-0MQ socket.
Other application subscribe this socket via a “sub”-0MQ socket and when they find a domain event they are interested in, they do something. 0MQ is heavily used in our application to bring programs (written in non-Smalltalk languages) nearer to Gemstone/S.
Our CATI-system is now a bundle of more than 20 processes (including Gemstone/S processes) written in Gemstone/Smalltalk, Python, Java or C#.
The communication is done either via https or 0MQ.
I now reuse this pattern in the area of logging the application information.
I use this 0MQ-pattern to bring all log-information to ONE log server – this time again written in Python.
The log-server (in Python) offers a pull-0MQ-socket and and a pub-0MQ-socket. All applications are sending their info/warning or errors messages to the Python server (the Gemstone/S database is again only a client here). This Python server now writes the data via the very nice Python logging framework to the filesystem.
AND it publishes (after it is written into files) the stuff again on its “pub”-socket – so other processes can subscrive to that socket and do additional stuff with the log messages. An idea could be a 0MQ to WebSocket relay – so that a simple WebApp can be used to get all logging information viewable in a browser in realtime.
The Gemstone/S server writes informations about incoming http requests, if they have done a commit, what the URL was and how long it tool to service the request. Also if an exception has been thrown and if a callstack can be found in the LogEntries of Gemstone/S.
Even though I have not posted anything since October – we were working hard to rollout out our CATI-application to a customer – we did this just before Christmas to stay in the project timetable.
We switched to Gemstone/S 3.4.0 as our base development/deployment system. Several changes have been done since then:
- The Python code generator had to be rewritten to be similar to the C#, ExtJS and Java generators – so the programming model ist now very similar on each platform. We decided NOT to follow the general Python principle – but to make function names equal on all supported languages
- The first Java application has been integrated into our Gemstone/S system and is now using the PUM API/Model. We went through two iterations until our developers accepted the generated code.
- On the modelling tool side – we were switching to VA Smalltalk 9.0.
Now we have four languages in our project and this seems to be getting a normal approach for all developers in this project. This is a good indication.
I have a wish, that there might be a Gemstone/S day at ESUG next year – with more content/presentations/Talks around that product. Perhaps user cases, how development is done and what has been achieved over the years ?
I know that there are many, many interesting projects out there and I would like to hear and see those projects – presented in talks.
And there are more topics around this technology I would like to here about. Some of the topics I would consider:
- Jade – how does the interaction with Gemstone/S works
- Jade – extending the Dolphin UI with special own needs
- tODE – current state and presentation
- Using indexes under Gemstone/S – problems, pitfalls and all that stuff
- Special concurrency support: RC-Classes, Counters
- Events from GEMs to GEMs, why, where and how
- Administration Task – Starting, Stopping, Backup, Restore, Updating
- Short introduction into the C programming of Gemstone/S
- How does it work Java and Smalltalk against one stone
- Development model under Gemstone
That are the topics I would like to hear about …
Further ideas ?????
When creating models with PUM there were places where the user could type-in text for documentatation purposes.
Actually this was only meant to be ASCII text, but today we moved away from that and now we are moving towards the XML based documentation process introduced by Microsoft: Sandcastle and/or NDoc.
The documentation is still exported for the other languages also, but now the documentation everywhere includes the XML-tags introduced by Sandcastle and NDoc.
Starting with that we create the documentation for our public APIs by using Print&Manual and their Sandcastle version – leading to a HMTL based documentation for the core code.
A newly created source code from PUM should now be copied to the client projects in VS2017, compiles it and Print&Manual calls Sandcastle to produce the content and then publishes the result as HTML-pages – a typical job for Jenkins under Windows.
Now, with this target in mind, I had to write more documentations in PUM with much more information.
I added support for persistent shared counter objects available in the Gemstone/S system. Due to the limited number of such objects in the database (around 1500) the usage is normally done only in singletons or cases like this.
For the client developer it looks like a normal (read-only) integer numerical attribute.