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:
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 …
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.
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.
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
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 … and I think that copy node in the tree, paste in the reference editor can be nice, but not that easy to do currently
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!
See 