XP8 changes and features - we need your input!

[tsi]

We have just started to look at the scope of XP8, a release that will introduce breaking changes for the platform. Our goal is to minimise the number of features and changes in xp8, in order to make the transition as smooth as possible. However, on popular demand - we now reach out to you! (the community) with a simple question:

What are your top 3 desired changes/improvements/features for XP8.
NB! Non-breaking changes/features may be introduced both before and after XP8 - as such, your input is highly valued

NB! There is currently no timeline or planned release-date for XP8.

[Rolf]

1. Schedule publishing of changes for already published content
2. Support for quick edits in content studio where you can edit certain content fields without loading the entire preview, similar to Wordpress quick edit. I guess the fields would require some form of annotation.
3. Support some form of advanced search (like NoQL), so I can do _path contains “/this/path/”, and sharing of those searches with others, for instance by using URL query parameteres

(The two first ones comes from CRM and marketing in our company, and the last one is just me )

[bwe]

Not likely all of these are actually breaking, but here’s my three in reversed order:

1. First take on data migration logic, like oldField -> newField and oldItemSet.field -> newItemSet.something, even system for moving fields between different content types, parts, and so on. Changing data modell would store some value in the node layer, this can be used to write upgrade modells for each version. Each version history entry is tied to a specific modell version and upgrading the modell would flag version history in a way so you cannot keep rolling back to older versions of the app (unless it could figure out/understand how to downgrade).
2. GraalVM (bye bye old ES5 and Nashorn), maybe even native Typescript controllers (with typing)
3. Possibility to deprecate parts/layouts and specific fields (don’t think that would break anything though).

[tom]

Problem: Naming functions delete

Since delete is an operator in JavaScript, variables cannot be named delete.

This becomes a problem, when XP expects my controller function to be named delete, and I’m using JavaScript module syntax instead of CommonJS syntax.

(There is a workaround for this by naming the function something e.g del and doing export del as delete, but it dirty, and unintuitive for beginners.)

Solution: Let the delete controller be named something different

I’m working with SvelteKit at the moment and they have decided naming the DELETE controller del.

From the SvelteKit documentation on endpoints:

Since delete is a reserved word in JavaScript, DELETE requests are handled with a del function.

Related problem: Library functions named delete

The same problem occurs when we are trying to import library functions named delete() using JavaScript module syntax.

Solution: Rename

Maybe renaming delete() functions to remove() could be a good fix.

[tom]

Problem: Naming collision on get()

It can be a problem – when using JavaScript module syntax – that both the GET controller and the function in contentLib for retreiving content is named get().

The workaround is pretty simple, the developer can do import { get as getOne } from "/lib/xp/content" to name the imported function something else.

But… The two get() functions are used alot together. It’s maybe the most used pattern in XP-development. A get() controller, that returns page based data retreived by using get() from contentLib.

Possible solution 1: Rename

Rename contentLib.get to something different. It can e.g. be getOne or getContent (but then I would suggest renaming portalLib.getContent() to portalLib.getCurrentContent())

Possible solution 2: Alias

Keep the contentLib.get() function, but also create an alias like contentLib.getOne() that can be used by developers that want to avoid this collision.

---

Bonus: Other get() functions

There are more get() functions in XP, like in contextLib, projectLib, staticLib and taskLib that can use the same renaming.

[tom]

Problem: Absolute paths are not supported in TypeScript tooling

TypeScript does not support absolute paths as module names, and I don’t think CommonJS does either, even though it is supported in Nashorn.

For the enonic-types library I’m using a hack where I put a wild card in front of the paths, to be able to resolve the absolute paths provided by the different xp libraries.

declare module "*/lib/xp/content" {
  ...
}

The problem is that my IDE will suggest to me which library to import a function I typed from. And if I select an XP library, it will spit out a broken path with the wildcard in front like this:

import { modify } from "*/lib/xp/content"

And that kids, is why you shouldn’t do hacks!

Solution: Stop using absolute paths in XP8

Use another mechanism to resolve paths in XP8. I don’t know which, but moving away from Nashord will probably provide some good possibilities.

[myurchenko]

1. Add read only config for input types, or config, which allows to change input by some specific user/role.
2. Add possibility to allow different parts for different templates.
3. Enable exports.patch. Seems like it is not allowed to have patch endpoints atm.
4. Progressive JPEG support for portal.imageUrl
5. Better logic for custom URLs. When creating API using Enonic all routes stored in site.xml. Maybe add a possibility to store routes in different files and import them.

[tsi]

1. This is already in our backlog, closing in on the top of the list :-). May require XP8
2. Interesting idea, a solution might be to support editing of meta-fields like path, displayname and similar. I guess doing this from the detail panel would be the least intrusive approach? This would not require XP8 anyway.
3. Improved search in Content Studio is already in our backlog, and does not require XP8

[tsi]

1. Yes, “patching” is something we are definetly looking at - hope we will be able to fix it for XP8, or a later release. It does require changes to the storage core.
2. Graal is definetly on our list, we have a working prototype - now dealing with multithreading
3. Makes sense indeed. Added this one to the backlog (Does not require XP8)

[tsi]

Thanks for raising this issue, seems like supporting “del()” is the way to go for JS modules.

[tsi]

We’re discussing adding aliases for framework functions i.e. httpDelete(), httpGet() etc.
Getting back with more info later.

[ase]

@tom Here’s a TBD issue for supporting aliases: https://github.com/enonic/xp/issues/9130

[tsi]

FYI: This is not nashorn specific, but our own XP framework implementation.
You do not have to use absolute path’s as documented here: Global objects and functions - Enonic Developer Portal

Also, we probably need to improve the docs a bit here with more details. Will investigate this further.

[tsi]

Thanks for the input, but 5 is bigger than 3

1. Good idea, might be some pitfalls but we’re adding this to the backlog - no ETA. Does not require XP8.
2. This is a bit unclear - could you explain a bit more what you need? There is currently filtering for parts based on content types at least.
3. Good catch, we’ll fix this shortly. Does not require XP8
4. That would be nice indeed, adding to the backlog - Does not require XP8
5. Hi. You can use the routing library to simplify this, so for instance you would then create a sigle mapping: /api, and everything inside is handled by your router: Router Library - Enonic Developer Portal

[tom]

@tom

For the enonic-types library I’m using a hack where I put a wild card in front of the paths, to be able to resolve the absolute paths provided by the different xp libraries.

@tsi

FYI: This is not nashorn specific, but our own XP framework implementation.
You do not have to use absolute path’s as documented here: Global objects and functions - Enonic Developer Portal

I don’t think any of the options in the documentation can help me.

My problem is very specific to enonic-types, and being able to add types to the different library packages (like /lib/xp/content). Unfortunately my problems are passed on to anyone using enonic-types.

---

I think the only way to get the IDEs working correctly with library imports, is chainging the import path to have the same “shape” as node imports.

That doesn’t mean moving everything to npm, maybe some aliasing when resolving paths would do the trick.

But the shape of the path should be something like one of these:

import { query } from "lib/xp/content"; // unlikely to work from anywhere?
// or
import { query } from "lib-xp-content"; // like a package in npm
// or
import { query } from "@enonic/lib-content"; // like a namespaced package

---

I have found another issue regearding this.

And that is if I copy code from one file to another, the import of functions will be copied too, but it will be changed to be */lib/xp/content, and then the developer will need to remember to manually change it, or it will fail at runtime.

---

Parting thoughts:

Creating TypeScript-types for paths that start with a "/ " has been challenging. It took me over a year to hack it.

So since XP8 is in the planning, I was hoping you would consider changing the way we reference libraries so that developers can get better IDE support.

Thanks
– Tom