JS: centralising configuration and state in for the Neos UI

There are lots of situations where module x or component y needs to know the current workspace, the current site node, the current content dimensions etc.

What we do currently is

  • trying to find a good spot for a property in one of the controllers or
  • read the data from the HTML markup

The latter seems to be “best” practise at the moment, very often these variables are determined like this:

workspaceName = $('#neos-document-metadata').data('neos-context-workspace-name')

I currently need to work a lot with “current workspace” and “selected target workspace” and I’d like to improve the situation a little (instead of worsening it). What are your ideas regarding cleaning this up in mid-term? Would be something like a “WorkspaceManager” (or controller) be a common solution?

I think a centralized place absolutely makes sense. I am just not sure if anything useful in that regard can be done before actually tackling a full JS refactoring. Anything done now will probalby not fit in there later…

I see. But it get’s tricky now already: for example, the “current workspace” is determined from the markup generated by my all time favourite class, the ContentElementWrappingService. I also need the “base workspace”, so I added that information to the markup, too. However, the document’s markup is cached of course, so if the base workspace changes … :astonished:

I can imagine 5 ways to implement that differently, but I hoped that we could agree on a direction at least. The more features we add, the less realistic is a full JS refactoring as you suggest.

Hi Robert,

I’ve wanted to do this for a long time however still haven’t gotten around to do it :smile: See https://jira.typo3.org/browse/NEOS-616

Regarding the refactoring, I don’t think that needs to block it since we need to come up with a concept anyway and doing that now could be fine. Additionally a JS refactoring will probably take a long time to become stable for a release and intermediary releases on the 2.* branch likely make sense.

@aertmann thanks for the pointer! I’ll at least keep it in mind for my further development.

Hey Robert,

I’d create a “Singleton” in Ember-Land where this information is residing – and which you can inject and use to fetch this meta-information.

I think that’s also what Aske means.

All the best,

A bit OT, but also somehow related: having a single Node model in JS (instead of one for inline, one for tree etc): https://review.typo3.org/#/c/38225/

I think it probably makes sense to have a readonly representation of the “current context”. Just one remark: There might be a time where there are multiple current contexts (e.g. in the split view) so a singleton might be an issue - although we’d probably use iframes for these things anyways…

@bwaidelich but if it’s read-only, we’d have to reload the whole window in order to apply changes. I’d be more in favour of establishing a Singleton / state object like Sebastian and Aske wrote.

I thought about it a little but I didn’t come to a conclusion yet what a good model structure could look like (based on Document? based on user preference?). I think it makes sense to sit together and design this more carefully instead of throwing in something half-baked now.

I think we’re on the same track. I meant “readonly” only in the sense of a “ReadModel” so that you can’t do s.th. like currentContext.workspace.name = "new-workspace" and expect it to do something on the server side.

Maybe it’s a good idea to reflect the content context (partly). At least it would make it easier to work with if server- and clientside are roughly in sync, also naming wise

I agree to the Ember singleton approach, we definitely need that and if it’s generic enough it will survive the refactoring probably :wink:

Can this kind of component “Ember singleton” can be used to have a central object for currently cut/paste node ?

Yesterday I have to use the references editor to link to a node named “Contact” … with a lots of other node using this term :wink: … and I think that copy node in the tree, paste in the reference editor can be nice, but not that easy to do currently

Hey Dominique,

Well, I’d probably use a different “Ember singleton” for storing this copy/paste information (actually I think this one already exists!?) – So we could implement that feature I think!

All the best,