What’s the big idea? A programming language that business people and programmers alike can efficiently write and read.
Moqui is all about doing things in a way that is optimized for developer time. It’s so optimized that I think it’s possible for less technical business people to be able to look at the code and even make changes. These would mostly be power users, but would be useful to help them understand how the code works at a higher level (the business level) and even make changes.
I was thinking about the simplest way possible to design a language. What’s more simple than a language that most kids now days learn called: https://scratch.mit.edu go ahead and try it out. It’s fantastic. It’s meant for beginning programmers and teach to program in the easiest way possible to learn. In my experience, this is all business people really want to learn. They don’t want to learn about text editing or programming. I think that this is a great interface for an initial design of getting requirements and business logic from business people.
Implementation:
To the left of the screenshot above, is an interface that is from a library called blockly it is the underlying library of:
It is already internationalized, and can export to javascript, python, php, lua, dart or can be expanded to export to other languages. It’s written in javascript and has a seemingly good api that is flexible for hacking on it. The actual blocks can be implemented in with json or javascript. The UI can be customized as needed and supports right to left support.
Ideally, the coding could be collaborative. For example, a web user creates a service and describes it with the gui. As the web user is writing this, the developer can see updates from their text file. The developer can then use the description and service definition and can implement it with their text editor. As the developer is writing it, the web user can see the updates. When the developer finishes a first pass, the web user can modify bits of the code to be as they intended it to be.
That’s great, a neat idea. It would go along well with a plain text editor like you described, and both could be backed by some sort of git integration like we talked about a while back (use jgit, save locally in a file or use DB somehow for server local git repo, add commit/push/pull/etc sorts of options, for UI perhaps extend the ElFinder file browser already there to add git options when applicable).
Some general thoughts on what you have so far…
In the visual example it breaks down the groovy script vs just allowing arbitrary text entry for expressions. If the language support in the tool is adequate to parse and generate groovy that would be very cool, but even as a sort of visual XML editor it would go a long way.
On being a sort of visual XML editor, that might be an interesting use of this visual style. If it already had some sort of XML support that would make it easy, otherwise maybe some sort of XSD to JSON templates to translate the Moqui XSD files into Blockly JSON files (or JavaScript if needed, I haven’t looked into details but my guess is with options like JSON and JavaScript that you have options with JavaScript that you wouldn’t with JSON).
If it’s good enough as an XML editor it might be interesting for editing screens/forms and such, or on the logic side of things a service definition + actions implementation to do all in one. I’ve thought a bit about doing a 2-way editor (read and write the xml files) and one issue is with manually formatted XML files (like all current files) when you save out the file you lose the original formatting and that causes changes management issues (lots of false positives on lines changed). If the file was originally generated with the tool then it can be much more consistent across changes. The best practice might be to always do one service per file to make change management easier.
I think that it would be better to extend the xml actions language rather than using groovy scripts and syntax. It’d be a lot easier to create blocks for and use from a business person perspective. The whole point of this is to keep it as simple as possible for both our sake to implement and easier to fit in the less technical people’s brains. Adding basic syntax would also make the xml actions language a more complete language overall and would make relying on groovy less necessary (you could even do things like using groovy as an interpreter, but also compile to java things that need to be more efficient).
This could be a good way to implement it. Maybe it’ll work.
For editing screens, using something like https://grapesjs.com/ would be way better. Just because blockly could be used for a html like editor doesn’t mean it should be (in fact I think it’d not be great at it).
I think that this could be really cool. You could have blockly define the logic and something like grapejs define the screen as an all in one editor.
For formatting we could use something like https://editorconfig.org/ which is a way to configure most if not all editors out of the box. Might also want to use https://prettier.io/. Another option is to seperate them. Have the developer formatted code viewable to the developer in seperate structure, and have web user formatted code editable by the developer, just without the expectation of keeping formatting.
[quote=“jonesde, post:2, topic:374”]
The best practice might be to always do one service per file to make change management easier.
[/quote].
I think this would quickly turn into a mess. A way to fix this is to make the same structure a developer has in the gui to allow for a 1:1 mapping of concepts between the two.
This might be doable in a way that is flexible enough to not need Groovy expressions, at least for most cases. My attempts to do this sort of thing in the past have resulted in really ugly verbose XML (something like a ‘.’ replaced by an XML element with sub-elements for subsequent ‘.’/etc). This is especially true when you get into conditional expressions like in trinaries and such.
The from attribute for example would have to either be turned into an element with sub-elements for more complex expressions, or use the from attribute as-is but also support a sub-element that expands on the text value of the from attribute (ie from would be a single field name, sub-elements would say how to get things inside it like from a Map, List, or general Object… could include field names as well as methods and be nested for further navigating an object graph).
For the widgets part of the screen it would not be a WYSIWYG sort of editor but still might be useful, and we’ll need something for the rest of a screen as well (even if some sort of super-simple transitions/actions/etc that just call a service or something).
If Blockly and GrapeJS will work together in the same web page it might be interesting to fit in both… or the other approach where ‘all-in-one’ is true of the app, but we have different screens for each.
FWIW, to use GrapeJS with a XML Screen might be a bit of work… using XML with a schema very different from HTML, and something that needs to be processed server-side as opposed to HTML and client rendering. This is part of why I was thinking that a more code-ish block editor for the XML file might be an interesting stop-gap that allows users to do more without the fancy tool we’d like.
The issue I’m thinking of is whitespace as opposed to concepts. If a large mantle-usl services file like OrderServices.xml (2451 lines) was parsed and then regenerated from just MNode objects (or Groovy Node or whatever) then we lose the formatting. Running this through the IntelliJ XML code formatter bumps this up to 3042 lines, mostly from things like always putting each open and close element on a new line (in much of the manual formatting this is not done, sort of like C/Java formatting there are a lot of </if> elements and such at the end of the line for single-statement if bodies).
Java code is often structured as one file per class, which is the reason for hierarchical packages and such. One service per file would require some work to get to, but could be automated with some sort of convention for file and directory naming. The real pain of that would be if we couldn’t do it an support the same service names… which means we’d maybe need to change the ServiceFacade to handle a filename like update#OrderStatus.xml (or some variation, not sure ‘#’ is allowed in a filename) that contains a single service element, and perhaps even allows not specifying a service name because better if we get it from the filename for consistency. That service file would go in a directory called ‘OrderServices’, and then I think we could support the existing service names.
The alternative for backward compatibility would be a bit ugly, somethings like move all services to new locations and then leave aliases in each original service XML file to point to the new locations. Service aliases are expanded at config load time so there is no performance overhead, but do result in multiple ServiceDefinition objects, but they do share some data so it might not be too much more memory.
The main reason to do that is that it minimizes the risk of causing problems with other services, including white space changes but possibly much more if something goes awry and there are 50 services in a single file.
For manual editing it would sometimes mean more tabs open, and creating new files for new services instead of just dropping them into some existing file. If we moved to one service per file it might make things better organized overall in a big service library like mantle-usl, but it would make it more difficult to trace back code history (rarely done, sometimes important like for the nightmare of a license change and tracking down all contributors, and eliminating code from contributors you can’t track down).
Anyway, we could use this approach even if we don’t use it for all mantle-usl services (which I wasn’t originally thinking about, but as I consider one file per service more, it might actually be an improvement… might). The editor could just save to a new file for each new service and then at least those would be that way.
