EL [ ] syntax - HSF page 393...

[Neil Mc]

Not sure if I'm missing something about the syntax of the [ ] operator in EL. HFS states that if the thing within the brackets in not in quotes, it is evaluated as an attribute...

On the 3rd question down, in HFS page 393 we have...

${requestScope[integer]...}  

Now... integer is not in quotes, so its evaluated as an attribute. We have an 'integer' attribute which evaluates to an Integer object with a value of 3. So does that not evaluate to...

${requestScope[3]...}    

Which would result in the '3' being treated as a key into the requestScope map ??? and there is no '3' key into the requestScope map (i.e. no attribute in that scope with the name 3.

What I'm trying to say, in my long-winded way, is should integer not be in quotes ??? This way it would just be treated as a key into the requestScope map. i.e.

${requestScope["integer"]...}    

Thanks.

[Colin Fletcher]

Neil,

Do you know what the result will be of using an attribute that is not defined ?

[Neil Mc]

null.

I see what you're saying, but the attribute is defined.... and maps onto a key which isn't present in the Map..... which would also return null. Which in this case is false.

So, you're saying that is part of the answer ? The explanation says nothing about it, which is a little misleading.

If thats the case, I'm delighted as it means my original understanding of the situation is correct.

Is it ? or am I missing something else here...... ?

[Colin Fletcher]

Neil, the attribute "integer" is NOT defined. Look very closely at the code again.

[Neil Mc]

Line 4 of the code.....

request.setAttribute("integer", i); 

Looks defined to me.

[Kathy Sierra]

Neil, I think you have it exactly right. This is one of the tricks of that question... that indeed while there IS an "integer" attribute, without quotes it is evaluated as its value ("3"), and then that "3" is used as the map key for the request scoped attributes. And as you said, there IS no request scoped attribute with the name "3". In other words, there is no "3" key in the map of request attributes. So... that's one issue with the question, and you're right, we didn't explain that aspect at all. But you figured it out based on what's the previous pages explaining the effect of using (or not using) quotes around the name of the attribute.

And of course, that didn't have anything to do with the final result, since you ended up with:

${requestScope[integer]...

Which becomes

${requestScope["3"]

Which becomes essentially null/zero in this case...

Which leads to:

0 ne 4

Which becomes true.

So then you still have...

true and 6 le num (where num is coerced to the int value 2)

Which becomes

true and false

Which becomes...

false.

Finally, you have

false || false

which gives you the final answer of...

false.

At least I think I said that right...

Does that help?

You were thinking about it absolutely correctly, and we should have given that a longer explanation. As it stands, you kind of have to piece it together using pages 374, 375, and 395.

cheers,
Kathy

[Colin Fletcher]

Sorry Neil, I must have missed the request.setAttribute line..

[Neil Mc]

Excellent guys.

Thanks for your responses.

[Sami Sayeed]

Hi Kathy,

<%@page import="java.util.*"%>
<%
String num="2";
request.setAttribute("num",num);
Integer i = new Integer("3");
request.setAttribute("integer",i);
// if you have something like
//request.setAttribute("integer","3"); //then it would work
request.setAttribute("3","3");
Map m = new HashMap();
m.put("1","one");
m.put("2","two");
m.put("3","three");
request.setAttribute("m",m);

%>
\${requestScope[integer]= ${requestScope[integer]} is not evaluated to 3 as you have stated.

[Kathy Sierra]

Actually Sami is right--the value of the "integer" attribute on page 393 is an Integer *object* and even though it has an int value of 3, in this case, it is not coerced to the String value "3", so even if there WERE an attribute with the name "3", it wouldn't matter in this case.

So... the answer is still the same, but the reason is slightly different:

${requestScope[integer]...

Which becomes

${requestScope["3"]

Which becomes essentially null/zero in this case...

Should really say;

${requestScope[integer]}

Which becomes

${requestScope[integer does not evaluate to a String so it makes no difference]}

Which becomes essentially null/zero!!

So... this kind of surprised me and if Sami hadn't tried this, I wouldn't have noticed...

Here's a little example you can do in Tomcat;



<% Integer i = new Integer(3);
request.setAttribute("integer", i);
%>

${requestScope["integer"]} // returns 3--the value of the attribute, i, an Integer, is coerced to "3"

${integer} // also returns 3 for the same reason

${requestScope[integer]} // null -- without quotes, the value of the attribute is assumed to be the name of the attribute, BUT... it does not attempt to get a String value from the Integer object!

FYI--you won't have questions on the exam about this particular scenario.

Thanks Sami! Good test... so now I know why I never explained this in the book...

And to Neil, you were still thinking about it in the right way, it's just that my explanation of the behavior for what EL thought was the actual value of [integer] was incorrect. It DID see [integer] and attempt to use the VALUE of that attribute as the *name* of an attribute, it did not see the value (an Integer object) as anything beyond an object... it didn't go through the extra steps of turning it into a "3".

Hope that makes sense still...

cheers,
Kathy