Proposal: Extending or rewriting comparison view

[florianschieder]

Disclaimer

I think this might be a reasonable proposal, but I'm not sure if it is indeed, if anything being explained here is unclear or not the right place to be discussed here. I'm open for any further ideas, doubts and remarks.

Use case

We are currently migrating our django-cms based codebase to v5, including moderation and versioning.

Our content managers would like to be able to review differences which are not visual. For example, one who did some changes and one who reviews the changes would like to see e.g. which image alternative texts changed.

Of course, this could already be derived from the source comparison. In reality, this would for our system be impractical for 3 reasons.

• It is very "frightening" for people who are absolutely not in touch with programming.
• A simple plugin attribute change might result in a huge visual and HTML diff and other changes could be overseen or misinterpreted.
• For technical reasons on client side, some of our internal plugins render attributes like data-some-unique-identifier='1337' while 1337 being the plugin PK. Therefore, creating a new version always results in a wall of changed HTML attributes, which would, honestly, even for technical reviewers be a challenge to reflect actual impact of changes.

Proposal

We would very much appreciate to have three comparison types: Visual, Source and Plugin Tree.
The latter would obviously reflect the page plugin tree, to see which plugins were added, changed and removed. We have not yet thought about concrete design or implementation details. This is basically the high-level idea we thought about.

Caveats

• IMHO this mainly affects djangocms_versioning/static/djangocms_versioning/js/base.js which has, as well as the related bundle file, not been touched since 2018.
• It is (at least for me) unclear and undocumented how the according minified bundle JS should be generated. I think we all are aware about how to deal with package.json files and webpack, but I think it would (at least for me) be necessary to take a deep dive about the intention the files should be managed.
• The implementation depends on (IMHO) very old JavaScript code in djangocms_versioning/static/djangocms_versioning/js/libs which has not been touched since 2018 either. It seems like this is very old legacy code, partially based on a even older difflib implementation from the Python standard library.

Technical approach

If the proposal seems reasonable from a functional and conceptional point of view the comparison implementation seems (at least to me) being an entire rewrite candidate. It could either be an approach to

• move forward to other JavaScript libraries for client-side diffing and implementing the new "properties diff" by exposing HTTP endpoints delivering the plugin tree. Maybe this is something headless endpoints already can handle, or are meant to handle in future.
• move the diffing logic to Python entirely and use HTML/CSS/JS for presentation only.

Disclaimer: I'm not sure which or if any of these approaches is an idiomatic one.

Contribution

The german department I am working for would very much appreciate to have this comparison functionality at plugin structure level if this is a reasonable approach. When Django CMS community agrees and/or has further improvement ideas to that proposal, we would very much look forward to contribute that functionality to djangocms-versioning.

Many thanks in advance for all your time and patience!

[fsbraun]

@florianschieder That's an interesting, and as I see it, very practical hands-on approach. Clearly worth thinking about it!!

[fsbraun]

Indeed, it would be a in between case which could make transparent:

• Changes in the tree hierarchy (i.e. moves)
• New or deleted plugins
• Changes to plugins (i.e. changes in the plugin edit forms)
  This still would need the answer of some questions (is deleting a text plugin and creating a new one a change or a new/delete?). Also, it would not uncover changes in related objects, i.e. the addition of an Alt-Text to a filer image used (since this only is referenced in a plugin).

[marksweb]

I think it's right to bring this up. Any time javascript doesn't get touched for more than a few years, it's likely to benefit from a rewrite or significant change.

There's also the issue that it's hard to find frontend experts who contribute to open source, let alone our projects. So if there's an opportunity to bring things back to python here, it's something that would aid in maintenance and future updates.