Currently, we use three different types of AST in XWiki:
- XDom, which is the base and legacy format, used throughout the platform
- UniAst, which was first introduced in Cristal and acts as a simplified XDom entirely client-side
- Macros AST, which is used for client-side macros to describe their output
The latter was originally created as the output content of a macro is slightly different than the structure of a document ; notably, it may contain editable areas, which are contents that can be edited in a WYSIWYG fashion by the end user using the client-side editor (e.g. BlockNote).
The problem is we now have two AST types on the frontend: one for documents, and one for macros. To avoid making things too complicated, macros AST implements basically all features of UniAst, plus the ability to describe editable areas. So in a way, it’s a superset of UniAst.
But because we have two different AST types, it makes manipulation much more complicated. For instance, there two independent HTML converters, one for UniAst, the other one for macros AST. There are two type definitions, with two API packages. There are two sets of tests.
In order to solve this issue, I propose to remove macros AST entirely, in favor of an evolution of UniAst. Blocks (e.g. paragraphs, lists, …) and inline contents (stylized text, links, …) would have an additional, optional property to store metadata, which would serve two purposes:
- Store the future custom properties required by XWiki’s syntax, which allows to provide properties of any name and value on any block and inline content ;
- Store, starting now, the information about whether the block is “user editable”
For instance, let’s say a macro outputs a set of three paragraphs, in the form of a single editable block. The resulting AST produced by the macro would consist of one raw block with a metadata property stating it’s user-editable, and containing the three paragraphs as children.
This would simplify things a lot, allow de-duplicating a lot of code, and reduce the maintenance burden in the future.
Given macros AST is currently used nowhere but in two very basic macros built into Cristal, this shouldn’t create any migration problems.
What do you think?