VASmalltalk offers two frameworks to create user interfaces: WindowBuilderPro and CompositionEditor.
The WindowBuilderPro is the more usual approach and is available in all other IDEs like VisualStudio or Eclipse.
The CompositionEditor is the original IBM approach – and the opinions about this tool are very different among all users. Its a visual development approach and the main problem with it is, that one cam use in very easily in the wrong way – resulting a bad managable software: Spaghetti code in a visual environment.
But if you use it the way it is meant to be used it can be a very quick tool to generate simple dialog based software.
One of the most important points is, that you write your logic code in Smalltalk methods and the logic is in these methods – not in the visual links.
The visual links in the CompositionEditor should only be used to connect your GUI to your logic methods.
When creating the REST methods (via PUM) for VASmalltalk for our Gemstone system I noticed, that the interfaces do not match the CompositionEditor principles.
When working with Sencha JS you normally think in sets of instances. Under VASmalltalk you may consider thinking in single instances you work on. Therefore the Smalltalk logic methods should work on sets – but should also do the conversions needed from single instance thinking to set thinking – otherwise you will be force to do a conversion (and then you simply create too many visual links). Therefore PUM now now only creates Actions for the normal CRUD interface, but also ACTIONS for single instance handling and ACTIONS for base collection handling to get rid of all the conversions needed.
To summarize: The CompositionEditor is still a powerful tool to create simple form oriented application, but one should be aware to create lots of parts working together and not fill all stuff in ONE large part. The visual links should only be used to create the visual (GUI) events logic.