etc.to

 The next part to fix are complex attribute values. These are attributes where the content contains some JSP region like a JSP expression or EL expression. In tokenising we again have two possibilities: a JSP Content region within a JSP taglib tag and a JSP content region in a non-JSP tag (template text as far as JSP is concerned).

Since Eclipse parses both the template text (to allow for HTML/XML checking) and the JSP it needs to distinguish these cases. For non-JSP tag values (and all places where JSP scriptlets are used outside of a tag attribute) there are no quoting rules except the rules for the embedded language itself. So a properly escaped piece of code using a non-JSP attibute value would be:

<input name="thename" value="<%= "\""+ "\"" %>" />

The input tag is JSP Template text as far as JSP is concerned and hence the value part just contains Java.

The complex case occurs when a JSP scriptlet is used within a JSP tag attribute, like for instance the again properly escaped:

<navi:form id="aa" method="<%= DoMe.check(\"Test \\\"world\\\"\") %>">

As can be seen one needs a plethora of escapes even in the Java text. This is stupid and should be unnecessary but sadly enough it IS part of the JSP standard; probably added when they were drunk or on dope or something .

To get this fixed is a lot more work. As can be seen from the example we actually have two types of "JSP Content": normal content and content that is "JSP escaped". The subparsers parsing these content types for things like syntax highlighting must be able to recognise these.

[more follows later]