Reference presentation with a knowledge about the cell that will own reference presentation
Good afternoon.
I have a case when I have a common editor component for reference. This editor component should be used in different places with different grammatical cases (like Dative, Genetive etc). I would like to provide a common mechanism to annotate cells with some custom style to switch the case for this specific cell.
The problem is that MPS provides an idea of strict separation of model and model presentation in cells. So I can't find any place where I have an access to the current cell or can obtain this data somehow.
I've tried to do this with "custom cell" but there are a lot of additional steps should be done with cell to initialize it (for example, we need to create a substitute menu). These things can be seen in the aspects of EditorCell_RefPresentation.
I've tried to create a custom model accessor to store the editor cell inside. Initially, the model accessor invoked before the cell will know anything about the parent cell. So I need to update the text after it. For this purpose I use customer EditorCell that uses onAdd() method to add editorCell info to my custom model accessor:
But as I said previously, the substitute menu uses other code to get the presentation. This leads to the fact that changed text can't be found inside the substitute menu.
So, my question is how to create a reference cell with a presentation that knows about this cell. I want to make an invocation of the node method with some additional info that I would like to obtain from the editor.
Please sign in to leave a comment.
I don't know how to solve this on the editor level. On the model level there is an interface called ISmartReferent which you can use to provide different presentation depending on the context. It only gives you the source of the reference but not the link, you'll have to figure that out yourself. If the source has two references which point to the same concept but each reference should have different presentation then this won't work and you may need to move each reference into a separate concept.
This functionality is used to refer to inner base language classes differently depending on the context.