[eskape]

I’ve upgraded MyEclipse to:

MyEclipse Enterprise Workbench
Version: 5.0.0
Build id: [build id]

Now I get several “cannot be resolved” errors on my JSP pages in my project.
When I open one of these files in my browser, I do not get the “cannot be resolved” errors.

For example:

<logic:iterate name="list" id="item"> 
<% MyClass obj = (MyClass)item; %>
</logic:iterate>

The following error occurres in my project: “item cannot be resolved”

Another example:

<logic:messagesPresent message="error">
<html:messages id="error">
<%=error%><br />
</html:messages>
</logic:messagesPresent>

The following error also occurres in my project: “error cannot be resolved”

Can anyone help me resolving this problem?

Thanks!

[Riyad Kalla]

Your code is technically fine, the error is incorrect and it stems from the inability of the JSP parser to extract run-time behavior of taglibs at design time. More details here:
http://www.myeclipseide.com/PNphpBB2+file-viewtopic-t-13364.html

[Bernd Maierhofer]

Is there any way to rewrite such a JSP snippet so no error is displayed? Or any way to disable this error?

Bernd

[Riyad Kalla]

Bernd,
The ultimate goal of the JSP spec is to remove all the uses of scriplets (<% %> segments of code), so if you can avoid that, you shouldn’t get markers.

[warrenthebrown]

Using MyEclipse 5.0.1 I see the same problem as reported by the previous person. Although I might ‘understand’ your response, I don’t understand why a capability that was working with MyEclipse 4.x no longer works, and thus now causes development hardships if a number of jsp files make use of
<logic:iterate … id=”xxx” …>
<% xxx.something %>
</logic:iterate>

Thank you.

[Riyad Kalla]

Warren,
The problem is that the JSP editor got smarter, where as before it just ignored it. So now it’s trying to be (too helpful?) and marking what used to be valid, invalid. We agree it’s not a stellar state and have a ways to go to improve the validation controls. Hopefully this should get rectified soon.

[shieroi]

Hello everybody!
The same problem here, a solution is eagerly awaited.

[Max Vilner]

support-rkalla wrote in the FAQ (referenced in the link above):
“This problem most likely won’t be solved anytime soon as runtime evaluation of pages on the fly is an expensive operation and tricky problem to solve.”

In my oppinion, it shouldn’t be too difficult to include beans in design time validation without going into runtime evaluation. All that needs to be done is collecting all id attribute values of tags like <useBean>, <bean:define>, <nested:define>, <logic:iterate> etc. and have the validator check the name of new jsp variable against that collection.

Thanks.
Max

[Riyad Kalla]

Max,
That is most likely the best approach to making this problem go 80% away, but take a tag like:
<mytag blah=”arg”>
</mytag>

The evaluator has no idea what mytag does. But I think you are right that some generic way to extend a variable collector and compare it to the new var is going to be what the dev team decides to do.

[Max Vilner]

Riyad,

Of course there’s no way to validate custom bean-producing tags (if I uderstood correctly your point). However as long as all known JSP tags are covered we’ll be OK.

Thanks,

Max

[henk]

Of course there’s no way to validate custom bean-producing tags (if I uderstood correctly your point). However as long as all known JSP tags are covered we’ll be OK.

Why would there be no way? The most logical solution is to have a myeclipse config file somewhere in which you can define what any tag does in term of introducing variables into scope.

e.g.

<taglib uri="someuri" >
<tag name="sometag>
   <variables>
        <attribute name="somevar" defaultvalue="myvar" scope="page" />
   </variables>
</tag>
</taglib>


This would say that sometag from taglib someuri has an attribute somevar that injects a variable into page scope. Furthermore, a defaultvalue would be handy incase the attribute is set by an EL expresion which may be difficult or impossible to evaluate at design time.

I think the myeclipse team already has this sort of file somewhere internally; i.e. they have to keep the information of what the standard tags do somewhere (like the jsf loadbundle tag). Now all they have to do is make this DB of tag information accesible and editable by the end user.


		
	

[Author]

Posts