Standard Collection Editor with prefixes per collection element

Hi,

this is a very specific question regarding the standard mps collection editor. I want to change the look of the baselang InstanceMethodCall, which currently looks somehow like

myClassInstance.foobar(param1, param2, param3)

 

Now i want to make it look like .... 

myClassInstance.foobar(
     argName1: param1,
     argName2: param2,
     argName3: param3 );


However, this is not that easy. Param1, Param2 and Param3 are Expressions. They are referred as %actualArguments% in the InstanceMethodCall editor. Just the standard (horizontal) collection is used. For each element (expression), the Editor from the particular expression concept is viewed. Thus, i can not easily prefix those collection elements with the name of the param from the InstanceMethodDeclaration (the argNames here).  

Is there a way i could somehow prefix the collection elements? One could think of the "separator" in the collection editor, but the separator can only prefix elements with the same text basically. 

Anyone a suggestion? 

 

Daniel

 

 

 

 

 

 

 

 

 

10 comments
Comment actions Permalink

Interestingly there is a bug in that separator query i mentioned above. 

To that separator query a "node" is passed. During runtime, this is the pervious collection element rendered, in the inspector window, it s the concept containing the collection. In my example, the InstanceMethodCallOperation ....   

0
Comment actions Permalink

Hi,

I've overridden some of the default editors in my "MPS extensions" project once. I added something similar you are asking for for argument lists that have more than two arguments:

 

Layout is a bit different then what you want, but you can still have a look at the project here: https://github.com/digital-ember/digitalember.extensions

The way I did it you can find in the overriden editor component IMethodCall_actualArguments for the "actualArguments" ref node list by providing a conditional styling (if there are more than two arguments). I cannot tell you off the top of my head if the same would work for your preferred layout, since styling is often a trial and error approach to me...

0
Comment actions Permalink

Hi Robert,

thanks for your comment - i just had a look at the repo. I m familiar with MPSs editor hints. However, i m still hoping that i do not have to overwrite all editors of various available expression concepts in baselang, just to get this feature implemented. 

Let me add at this point, that i m not using the InstanceMethodeCall directly but MyMethodCall which is almost a copy of InstanceMethodCall. I do also reference InstanceMethodeDeclaration. So i can provide my own Editor for the MyMethodCall.... i did not mention this in my original post. 

So basically i m looking for an editor for my MyMethodCall concept. Right now, i don't have n idea..... 

 

 

 

0
Comment actions Permalink

Well, if you already extend InstanceMethodCall, you might as well also extend the interface IMethodCall and override the editor component IMethodCall_actualArguments.

It was relatively easy in the end to adjust the styling so that your preferred layout applies: 

Be aware that, in any case (introducing your own extensions by means of sub-concepts or by means of using editor hints), your editor will likely lose some of the build in functionality of the base editor (like action maps, focus policies, etc.). You can copy the exisitng implementation and adjust it to your needs, but changes to the base editors will, in many cases, not be reflected in your sub-editors.

I would have to look a bit closer into how to add argument labels as well. Is it a must have for you?

0
Comment actions Permalink

This should be all the changes you need to get above layout (i.e., there is no need to touch Expressions):

0
Comment actions Permalink

Hi Robert,

 

thanks again for your quick response. As stated in the intro post, the prefix for each collection element is the problem. not the new-line on indent-layouts. 

 

 

0
Comment actions Permalink

You could try it programmatically (sorry for not reading your initial post closely):

 

 

0
Comment actions Permalink

Nice, this might be exactly what i was looking for ! 

Is it still editable with this approach? I.e. can the user still add a param4 in case a param4 is requested by the declaration? 

 

Amazing !! 

0
Comment actions Permalink

The example certainly lacks different desirable usability aspects. It was just ot give you an idea how you might be able to get the argument name along with your parameter w/o caring about what your parameter actually is. This solution has many drawbacks since the cells are created programmatically. You want to look into the reduction rule for CellModel_RefNodeList as inspiration how you build these editor cells (e.g. the separators) in a way the usability is good: http://127.0.0.1:63320/node?ref=r%3A00000000-0000-4000-0000-011c8959029f%28jetbrains.mps.lang.editor.generator.baseLanguage.template.main%40generator%29%2F1106598080605870079&project=digitalember.extensions

I cannot add new parameters with above solution by pressing "Enter" or typing in a separator, for example, but the parameter cells themselves are fully functional as one would expect.

0
Comment actions Permalink

Okay i will probably have an in detail look into programmatically creating editors ... 

 

Of course, another option is using r/o access and fabricating that look, which is very simple. however, this solution won't be editable as well.. 

 

Cheers  and thanks for your support....  

0

Please sign in to leave a comment.