As David mentioned, the new Public Draft available at jcp.org explains the
new behaviors. Just to explain where they come from (so they don't seem
arbitrary):
On Wed, 27 Mar 2002, Jean-Paul Le Fevre wrote:
> - I've a class which is extended from an AbtractList. I added some
> methods which are needed by my application (A couple of getSomething())
> but in my JS page, using <c:out value="${my_instance.something}">,
> an exception is raised complaining that a conversion to integer (?)
> is not possible for a List. It seems that the server does not
> understand that my_instance is not a pure List but something
> inheriting from a List.
To clarify, this was intentional. The spec reasons that if you provide a
an object that implements List, you're supplying a list of items -- and
that you don't intend for the object to supply arbitrary JavaBean
properties.
> - In a class I've a method preparing the list of options available
> for some choice : getOptionList(). It returns a string which is
> a concatenation of <option>choice A</option> ...
> But in the JSP <c:out value = "${sample.optionList}" /> is not displayed
> if it is nested in a <select></select> where it should be.
> To find out what was wrong I moved the <c:out> outside the <select>
> block and my string was displayed.
By default, <c:out> escapes characters that have special meaning to XML.
It's far more common to use <c:out> to display a simple (non-HTML) string,
where escaping is appropriate. To shut off this escaping, set the
'escapeXml' attribute to 'false'.
Hope that helps,
--
Shawn Bayern
Author, "JSP Standard Tag Library" http://www.jstlbook.com
(coming this summer from Manning Publications)
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
