JSP EL variable completion based on TEI classes: how does it work?

Yes, exactly as you described

Taras Tielkes wrote:

Are the TEI classes loaded by the IDEA JSP editor and queried for
variable info (getVariableInfo(TagData))?

--
Best regards,
Maxim Mossienko
IntelliJ Labs / JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"

Hello Maxim,

Yes, exactly as you described

Taras Tielkes wrote:

>> Are the TEI classes loaded by the IDEA JSP editor and queried for
>> variable info (getVariableInfo(TagData))?

To be honest, I'm completely stunned! If I had only known this earlier...

I've always thought that putting tag variable metadata in the TLD was the
way to go, and that TagExtraInfo was a legacy (JSP 1.0/1.1) way of doing
the same, basically.

However, TagExtraInfo is much more powerful in one specific scenario: conditionally
created variables.
Sometimes you have a tag that can render either to the out stream, or to
some variable (say when some optional attribute is present, "var" in the
following example):
<prefix:myTag value="$"/> <prefix:myTag var="renderedValue" value="$"/>

This is basically how JSTL, the Spring framework taglib and a whole load
of other tags work. The TLD variable declaration mechanism does not work
here, since the "var" attribute is optional.

Adding the TEI make it work, with the following comments:
-rename on such EL variabled causes an exception (reported)
-it does not seem to work in a reliable way (seems like difference between
TLD included in project versus included in dependent module, still trying
to find out...)
-it would be nice if the variable navigated (ctrl-click) to the defining
tag element
-it would be nice if Show Usages (Ctrl-Shift-F7) would mark the tag element
as a write (pink instead of blue) location

That said, total warnings in JSPX files decreases by 10% after implementing
TEIs...

Taras

Actually, TEI mechanism defines variables accessible by Java code and
EL resolve just pick them during EL var resolve.
However, right now (IDEADEV-9127) any 'var' on custom tag will cause
introduction of EL var accessible within file, thus you should get less
warnings without tld changes.

Taras Tielkes wrote:

Hello Maxim,

>> Yes, exactly as you described
>>
>> Taras Tielkes wrote:
>>
>>> Are the TEI classes loaded by the IDEA JSP editor and queried for
>>> variable info (getVariableInfo(TagData))?

To be honest, I'm completely stunned! If I had only known this earlier...

I've always thought that putting tag variable metadata in the TLD was
the way to go, and that TagExtraInfo was a legacy (JSP 1.0/1.1) way of
doing the same, basically.

However, TagExtraInfo is much more powerful in one specific scenario:
conditionally created variables.
Sometimes you have a tag that can render either to the out stream, or to
some variable (say when some optional attribute is present, "var" in the
following example): <prefix:myTag value="$"/> > <prefix:myTag var="renderedValue" value="$"/>

This is basically how JSTL, the Spring framework taglib and a whole load
of other tags work. The TLD variable declaration mechanism does not work
here, since the "var" attribute is optional.

Adding the TEI make it work, with the following comments:
-rename on such EL variabled causes an exception (reported)
-it does not seem to work in a reliable way (seems like difference
between TLD included in project versus included in dependent module,
still trying to find out...)
-it would be nice if the variable navigated (ctrl-click) to the defining
tag element
-it would be nice if Show Usages (Ctrl-Shift-F7) would mark the tag
element as a write (pink instead of blue) location

That said, total warnings in JSPX files decreases by 10% after
implementing TEIs...

Taras

--
Best regards,
Maxim Mossienko
IntelliJ Labs / JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"

Hello Maxim,

Actually, TEI mechanism defines variables accessible by Java code and
EL resolve just pick them during EL var resolve.
However, right now (IDEADEV-9127) any 'var' on custom tag will cause
introduction of EL var accessible within file, thus you should get
less
warnings without tld changes.

I see. But such a "brute-force" solution will not provide type information
(nice to have in completion popup). Besides, sometimes an attribute other
than "var" will be used. I guess this hack will also "fix" IDEA-6281. Anyway,
I guess it's a pragmatic choice.

So build 6003, is that 6.0.1 or post-Demetra?

And
1) Any change of having IDEADEV-7073 post-Demetra? That would push our JSPs
much closer to 100% green. (If there's a simpler way to do it I'd also like
to know, I cannot imagine that others do not have this problem)

2) Is there some description on how to make IDEADEV-4482 work (where do I
specify "context pages")?

Thanks

Taras Tielkes wrote:

Hello Maxim,

>> Actually, TEI mechanism defines variables accessible by Java code and
>> EL resolve just pick them during EL var resolve.
>> However, right now (IDEADEV-9127) any 'var' on custom tag will cause
>> introduction of EL var accessible within file, thus you should get
>> less
>> warnings without tld changes.

I see. But such a "brute-force" solution will not provide type
information (nice to have in completion popup).

We evaluate var type from items in c:for, there is request
IDEADEV-4975 for any custom tag

Besides, sometimes an

attribute other than "var" will be used. I guess this hack will also
"fix" IDEA-6281.

Anyway, I guess it's a pragmatic choice

So build 6003, is that 6.0.1 or post-Demetra?

6.0.1

And
1) Any change of having IDEADEV-7073 post-Demetra? That would push our
JSPs much closer to 100% green. (If there's a simpler way to do it I'd
also like to know, I cannot imagine that others do not have this problem)

Surely, since it is planned for 'Next Version'

2) Is there some description on how to make IDEADEV-4482 work (where do
I specify "context pages")?

Ask Hector :)

Thanks

--
Best regards,
Maxim Mossienko
IntelliJ Labs / JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"

Hello Maxim,

>> 2) Is there some description on how to make IDEADEV-4482 work (where
>> do I specify "context pages")?
>>

Ask Hector :)

I'm using Sitemesh, so perhaps I'm looking for something that doesn't exist...
Anyway, the only thing I get from Hector are
-highlighting level popup
-link to the errors profile dialog

Does this magical IDEADEV-4482 stuff only work for JSP includes?

Taras Tielkes wrote:

Hello Maxim,

>>> 2) Is there some description on how to make IDEADEV-4482 work (where
>>> do I specify "context pages")?
>>>
>> Ask Hector :)

I'm using Sitemesh, so perhaps I'm looking for something that doesn't
exist...
Anyway, the only thing I get from Hector are
-highlighting level popup
-link to the errors profile dialog

Does this magical IDEADEV-4482 stuff only work for JSP includes?

Yes.

--
Best regards,
Maxim Mossienko
IntelliJ Labs / JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"

Hello Maxim,

>> I'm using Sitemesh, so perhaps I'm looking for something that doesn't
>> exist...
>> Anyway, the only thing I get from Hector are
>> -highlighting level popup
>> -link to the errors profile dialog
>> Does this magical IDEADEV-4482 stuff only work for JSP includes?
>>

Yes.

I see.

In my Sitemesh situation the outer/including template has a <decorator:body/>
tag element somewhere.

I assume this is not very different from magical JSP include context support,
in terms of general structure?

Maxim,

What about an API a la ReferenceProvider for this stuff in 6.5?