Right now we only have a single “Extension Id” xproperty to link to exo.
Since frontend APIs may need to point to both a webjar XWiki Extension and a NPM registry package, we need to be able to indicate both.
For simplicity, I’m proposing to repurpose the Extension Id field to work as follows:
Rename it from “Extension Id” to “Extension & Package Ids”
Add a hint, to explain the format <extension id>|<package id>
Both the Extension id and the package id part is optional (we have some front end apis that won’t be published as xwiki extensions, e.g. pure types)
Pros:
We don’t need to change our documentation templates and make it complex.
In 90% of cases, we just need to specify the extension id
If we were to add a new “packageId” xproperty instead, we would need to display it visibly in the UI while it would be used in less than 10% of the cases, making the UI probably less easy to use.
Then if there’s a package id specified, I’ll add a badge at the bottom, to link to the NPM registry with a title of “NPM Package”.
This approach makes sense, but “optional” might sound too permissive.
If an extension id or a package id exists (i.e. the API is published as an XWiki extension or an NPM package), it must be filled in. I think the cases where neither applies (e.g. pure types) should be rather treated as exceptions (in the doc guide).
Now I’m wondering if it would not be more future-proof have a more explicit syntax, like using a prefix in front of the id (like npm: and extension:, which might be the default if no known type prefix is given) instead of relying on a position around some hopefully unique |.
Sure, sounds good, it’s more complex to type. Also we still need a separator.
My idea is that this field should be used for any ids (right now we have 2 but we could have more in the future). Also right now the input would be textual but in the future we could improve the id picker with a better UI if we want/have the time.
I was trying this on my local wiki and I couldn’t see how to change an xproperty type. Does it mean the only way to change the type is by exporting the page with the class to XAR, change the type in the XML, repackage the XAR and reimport?
EDIT: Also, does it mean we need to change the <class> entry inside the <object> entries in the XML of all existing pages (since the type there is the old type)?
To trigger the migration you need the type to be changed in a single save, so until XWIKI-19185 is fixed, you indeed cannot really change the type through the class editor UI. I’m afraid will need to go through either an import, indeed, or change the type using a script instead of using the UI.
If by “existing pages” you mean the extension pages, then ideally yes, it would be cleaner to export standard page which have been migrated so that the XML in the XAR is fully accurate. If you are not talking about extension pages, then I’m not sure what you mean.
You mean that if we had Loading..., we would need to remove the xproperty and create a new one with the same id (but of a different type)?
Another (better) option is to allow changing a property type through the class editor (without going through remove + create). I don’t know if we have an issue for this already.
Yes there are extension pages that need to be modified (like the template pages which have an xobject of that class).