New xwiki-platform-web-webjar module

Development
1

Hi everyone,

While working on auto-save for BlockNote editor integration (XWIKI-24372) I had to move some JavaScript code from xwiki-platform-realtime-webjar and xwiki-platform-web-war to xwiki-platform-node (and rewrite it to TypeScript) in order to re-use it for BlockNote integration. The moved code is still needed outside BlockNote (outside node “world”) so I had to expose it in a WebJar. I wasn’t sure where to create the new WebJar module(s) and given that the moved code is related to core XWiki features, I opted for the quick path of adding a new xwiki-platform-web-webjar. It currently holds 3 JavaScript modules:

  • entityReference: moved from xwiki-platform-web-war; the client-side representation of XWiki entity references; used in many places; I suppose this could be later moved to a xwiki-platform-model-webjar
  • document: moved from xwiki-platform-realtime-webjar but it’s not specific to real-time editing; it provides APIs to interact with an XWiki document client-side; currently used by CKEditor and BlockNote; note that inplace-editing mode (XWiki.InplaceEditing) defines its own xwiki-document-api module which overlaps with this one, so we’ll have to update the inplace editing module to use the shared one instead, eventually; there is no “document” top-level domain in xwiki-platform, and xwiki-platform-oldcore-webjar didn’t sound good to me
  • autosave: moved from xwiki-platform-realtime-webjar; this is related to real-time editing, but the issue is that the current xwiki-platform-realtime modules are ChainPad dependant, and this code doesn’t depend on the framework used to sync the changes (Yjs / ChainPad). I chose to put the code here until we figure out how to split the xwiki-platform-realtime modules into generic and ChainPad-based.

Let me know if you’re against this and I’ll try to relocate the code.

Thanks,
Marius

2

any reason for not having the model-webjar already? Wondering if document should be put there too?

Otherwise autosave feels more like some edit-webjar stuff no?

3

No. This code has no dependencies, and it matches the model domain.

It’s not exactly the model domain and, more importantly, this code depends on xwiki.js (client-side URL factory) and xwiki-meta (client-side “context”), both from xwiki-platform-web-war. It also depends on the REST API (page, translations, history). These dependencies must be made explicit in the POM. They don’t look right for a model WebJar to me.

That’s an option indeed. The auto-save acts on the edit form, i.e. the entire form is auto-saved, not just a specific field. This code depends on actionsButtons.js (from xwiki-platform-web-war), editactions.vm (from Flamingo skin) and the new xwiki-document discussed above.

Thanks,
Marius

4

Ok well the xwiki-platform-web-webjar would probably needed anyway in the future for other stuff, so I guess it would make sense to create it right away.

So if you’re ok, I’d say +1 for:

  • entityReference in xwiki-platform-model-webjar
  • document in xwiki-platform-web-webjar
  • autosave in xwiki-platform-edit-webjar

Now I’m -0 for the first proposal.

5

+1 for that as well, I agree xwiki-platform-web-webjar is unavoidable at the moment, but should be kept at it strict minimum.

6

I’m OK with this. Now, I’d like to reiterate that these modules won’t hold the code. The code is in xwiki-platform-node. These modules are only publishing the code as AMD modules, packaged in WebJars.

@mleduc I don’t recall if we discussed / decided when to move code to xwiki-platform-node and when not to. I started moving code in it (e.g. from xwiki-platform-blocknote-webjar and xwiki-platform-web-war), because it already contained code from many domains. The downside I see is that domains get their back-end and front-end separated. Consider a domain like “annotations”. The backend will be inside the top-level xwiki-platform-annotations module, while the front-end will be in xwiki-platform-node/core/annotations. This makes it harder to move domains outside xwiki-platform.

Thanks,
Marius

7

yes I already discussed with @mleduc that I don’t like to have a single mono module for front end code. He said he’d explore/research how to continue having business modules. I don’t know what’s the status on that.

8

Answer to both quotes at once. I agree I’m not a fan of the current organization either. And I would prefer to be able to be able to move the node code closer to the rest the code of each domain.
I haven’t got time to re-evaluate this yet sadly. The points to consider are:

  • The distinction between generic code that is not XWiki specific (e.g., Cristal)
  • The publication order, what happens in case of re-start of a release and so on (i.e., we want to make sure all packages are published in the right order, but we also want to make sure no packages is published twice)