References with different names

How can I define references with different name in a custom language?
Eq. an bean-property has methods
String getPropValue()
setPropValue(String)
and in the custom language file it is just used as
"propValue"

Goto-Action works, but Find Usages/Rename not.
So how can I do this?

9 comments
Comment actions Permalink

Hello Sven,

SS> How can I define references with different name in a custom
SS> language?
SS> Eq. an bean-property has methods
SS> String getPropValue()
SS> setPropValue(String)
SS> and in the custom language file it is just used as
SS> "propValue"
SS> Goto-Action works, but Find Usages/Rename not.
SS> So how can I do this?

This is not possible with the current Language API.

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"


0
Comment actions Permalink

Dimitry,

SS> So how can I do this?

This is not possible with the current Language API.

Maybe it would be a good idea to list in the upcoming LanguagAPI
documentation what's NOT possible with the current Language API(but
users would expect it since it's called Language API).

It's enough to read the posts on this forum and see where the answer was
"This is not possible(/ with the current Language API)".
Just copy&paste them.

I think this would ease very much the work of plug-in writers and will
reduce greatly the frustration with the API.

Thanks in advance,

Ahmed.

0
Comment actions Permalink

SS> So how can I do this?

This is not possible with the current Language API.


:( No work-around? No fake possible?
Arn't there similar things in JSP?

0
Comment actions Permalink

Hello Ahmed,

>> SS> So how can I do this?
>>
>> This is not possible with the current Language API.
>>
AM> Maybe it would be a good idea to list in the upcoming LanguagAPI
AM> documentation what's NOT possible with the current Language API(but
AM> users would expect it since it's called Language API).

The restrictions of the Find Usages/Rename functionality, and in particular
the restriction which led to the original question in this thread, are described
in quite good detail in the "Developing Custom Language Plugins" article.

Different users have very much difficult expectations for the Language API,
and I don't think it would be feasible to cover all of these in some document.

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"


0
Comment actions Permalink

Hello Sven,

>> SS> So how can I do this?
>>
>> This is not possible with the current Language API.
>>
SS> :( No work-around? No fake possible?
SS> Arn't there similar things in JSP?

JSP uses quite a lot of internally hard-coded logic which is not exposed
through OpenAPI.

There may be some work-around but I don't know of any.

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"


0
Comment actions Permalink

>>> This is not possible with the current Language API.
>>>

AM> Maybe it would be a good idea to list in the upcoming LanguagAPI
AM> documentation what's NOT possible with the current Language API(but
AM> users would expect it since it's called Language API).
The restrictions of the Find Usages/Rename functionality, and in
particular the restriction which led to the original question in this
thread, are described in quite good detail in the "Developing Custom
Language Plugins" article.

Well, I think there should be a chapter called "What's not possbile with
the LanguageAPI",
so that everyone reads that first and have an image about what to expect
from it. My point was to reduce user frustration by
digging/trying/failing and than after many lost hours to find out that
it's simply not possible.

Different users have very much difficult expectations for the Language
API, and I don't think it would be feasible to cover all of these in
some document.

Sorry but this is simply not true. Most people here would like(or hope)
to achieve with the Language API the same level of 'smartness' for
custom languages like with Java(of course with the according restrictions).

If you look in the tracker, most open requests regarding javascript or
other languages go in this direction.

Ahmed.

0
Comment actions Permalink

I tend to agree, though due to the nature of the (Open)API, it's virtually impossible to
either list the things are possible, nor those that aren't. There's also a very big gray
area of things that can be done by more or less ugly workarounds, which understandably are
unsupported by JetBrains.

A chapter about API limitations however, which describes lacking features that are already
known to be missing and maybe even planned (hooks into Smart Completion, advanced (non
OpenAPI) Code Completion, embedding custom languages into existing ones, etc.), might
indeed save some people from trying to do things that turn out to be impossible in the
end. Adding a new JIRA category "Language API" (and assigning the existing issues to it)
and providing a link to it would already cover a big part.

Sascha

0
Comment actions Permalink

So I filed an jira request:
http://www.jetbrains.net/jira/browse/IDEA-4810

I think most scripting/web language really need this.

Dmitry Jemerov (JetBrains) schrieb:

This is not possible with the current Language API.

0
Comment actions Permalink

Any news on this topic?
I got a lot of stuff already working in the plugin and this limitation
really hurts. Please help! Any way to get this working is welcome.

One point to convinced our boss to buy IDEA5 was the new language api.
But when writing the plugin I found so many pitfalls. Waiting for
release 5.5/6.0 is not an solution at all.

Thanks in advance

Sven Steiniger schrieb:

So I filed an jira request:
http://www.jetbrains.net/jira/browse/IDEA-4810

I think most scripting/web language really need this.

Dmitry Jemerov (JetBrains) schrieb:

>> This is not possible with the current Language API.
>>

0

Please sign in to leave a comment.