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.
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