Person is : <jsp:getProperty name="person" property="name" /> ID is: <jsp:getProperty name="person" property="empID" />
It all works.
In which it pointed out type has changed from "foo.Person"(from page 360) to "foo.Employee", which will further imply that:
the generated servlet will say: Employee person = new Employee(); instead of Person person = new Employee();
However, what's the point of this change? I tried to use type="foo.Person", which generate the same result as using type="foo.Employee". Both would print out name and empID after submitting the form.
Does anybody have a clue why type has to be changed here on page 361? Or the author is just trying to show either way it works?
posted 15 years ago
What is even more confusing is that, on page 424, the second last bullet point says: =============================== B]If you specify a "type" attribute in <jsp:useBean>, you can set properties in <jsp:setProperty> ONLY on properties of the "type", but NOT on properties that exists only in the actual "class" type.[/B] ===============================
Howdy Jessica, I'll answer the second question first...
That bullet point on 414 says: " If you specify a 'type' attribute... you can set properties ONLY on properties of the 'type', but NOT on properties that exist only in actual 'class' type..."
Is a tricky one. We do not believe that the spec guarantees the behavior you see in Tomcat.
The behavior of Tomcat would have us change that bullet point to say:
"If you specify a 'type' attribute but NOT a 'class' attribute... you can set properties..."
But we don't think this is technically a guarantee, as opposed to an artifact of how the generated code works in Tomcat and some other Containers. In other words, the way the bullet point is worded is the safest thing to assume, even though depending on how reflection is used in the generated code (which is the case of Tomcat), it might work anyway (you can set properties on the 'class' even if they do not exist in the 'type'), as your code experiment did.
Bottom line: to be safe, use what we say in the bullet point and do not try to set properties that exist only in the 'class' and not in the 'type'. But in practice, you may get the result that YOU saw--where if you DO specify both type AND class, it still works. If you specify 'type' *without* 'class', you should see this fail in Tomcat (in other words, you won't be able to set properties that exist in class but not type if you have specified ONLY type in the tag).
Anything that is not 100% defined in the spec will *not* be on the exam. So, you won't have to worry about this We're sorry about the confusion, though, and we should have made a point of talking about this. Because you're not the first person to have put that bullet point to the test and found that it DOES work in Tomcat 5.
In the other code, yes, we're mainly just showing you that you *can* specify both class and type, where type is a polymorphic reference. But you're right-- it usually has no significant effect if you DO specify both type and class (assuming the class is compatible with the type).
BUT... it does mean that if you *do* specify *only* type, then at runtime the actual object can be of any compatible runtime type. So I guess we were just trying to make the point (hmmmm... just in case it shows up on the exam ), that there is a distinction between "type" and "class", and the relationship between them.
So, to recap the other rules related to this:
* You can specify both type and class, and if you DO, the class must be compatible with the type. In other words, you must be able to assign an object of type 'class' to a reference of type 'type'.
* If you specify ONLY 'type', without 'class', then the bean must already exist. Remember, 'class' is used to instantiate a bean if one does not exist. The 'type' will never be used as an object type.
* If you specify ONLY 'type', then you can set properties only for those properties that exist in 'type', as opposed to those that exist in 'class'. If you specify both 'type' AND 'class', then you may be allowed to set properties that exist only in class and not type, but don't count on it
p.s. thanks for the good questions Jessica!! Keep it up...
posted 15 years ago
Thanks Kathy. The really helps. I guess I should not assume the behavior I observed from Tomcat 5 to be guaranteed by specs.
I also feel it would be nice if something like the following is added to page 360:
Depending on the container you use, you may get empID property set correctly or not, but name property will always be set, since it is a property defined on "type" Person.
Cowgirl and Author
posted 15 years ago
I think that's a great suggestion!
On the next printing, we'll obviously have a few things to clean up...
Thanks again to all you brave early adopters Kathy
If I had asked people what they wanted, they would have said faster horses - Ford. Tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop