Community
Participate
Working Groups
A tag <dmf:datagridRow> is defined to be expanded to <tr><td>...</td>. A tag </dmf:datagridRow> is defined to be expanded to <td>...</td></tr>. So a sequence ---------- (1)<dmf:datagridRow> (2)</tr> (3) <td> .... </td> (4)<tr> (5)</dmf:datagridRow> -------- will be expanded to the valid html: <tr> <td>...</td> </tr> <td> .... </td> <tr> <td>...</td> </tr> Such a tag using is accepted by Tomcat and IBM Websphere. JSP validation generate an error "no start tag <tr>" on the line (2). I have not found in the JSP 1.2 specification any requirements for the jsp tags themselves to be "correctly" nested. My proposal: to make a jsp nest regularity validation optional and controlled by an appropriate preferences/validation/jsp checkbox.
I don't know what dmf is, but doesn't seem like quite the right design, to me. But ... your point is valid. We do want to add more validation controls in the future, time permitting. But, I will put at P4, for now.
Hello David, your remarks on designing and maybe styling/beautifing seems to be of second importance, also in the case that you would be right. The code was citated from EMC-Documentum Web Development Kit. Since the webtools version 1.5 the WDK-projects are suddenly "decorated" in red. I think, it would be not a false measure to take a portion of that stuff in the test suits. The main thing is the conformity to the official JSP 1.2 specification. In moment the eclipse webtools does not support JSP but somewhat another like "eclipse-JSP". It really seems not to be an example of the sophisticated design. I have my doubts about the hiding the problem under P4.
I'ts actually a "DOM - JSP", by design (that is, we assume its still faily well formed according to DOM rules, as most examples we've seen are. Your example is a good counterpoint, and I was just wondering why they did it that way .... seems to force the user to add some "extra" tags. I made a '4' since I don't think there's much we can do about these non-DOM uses. Our thought was that it the text does not approximate HTML in the form of a DOM, then, users would just have to turn off validation for those. I dont' think there is much we could to to validate it, without "running it" and seeing what it produces ... which would be a whole other function, I think. I do appreciate it though, let us know if you know of or see many other case of non-DOM JSP files.
We have and will continue to try to do validation based on user expectations and what they find helpful (which is not necessarily the same thing as a runtime specification, as the JSP spec is), But agree we've had many requests for more preferences for users to control exactly how to do validation. But, as you may well appreciate WTP is very large and we are always short on resources. We are unable to do everything for everyone. This bug was marked to indicate that it is not high priority for us, but this does not mean that it is not important. We are always looking for feedback from users and yours is a very important one. Knowing user requirements such as yours is important to us to build tools that can be inclusive of most common scenarios. As I already said, this type of stuff is exactly where we need help. We would welcome all contributions in terms of feedback, patches and more. I know this is not much to offer now, but we will definitely assist you if you are willing to do some work to provide solutions for better JSP validators. Raising the priority to p3 and listing it as helpwanted
As has been so wisely stated by both David and Naci this is one of those edge cases that does not have a good solution with the way JSP validation works, as David stated a JSP-DOM like validation. As was stated in one of the comments the best work around for this type of case would be to turn off the HTML validation. Vote to close.
*** Bug 203286 has been marked as a duplicate of this bug. ***
*** Bug 306284 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 152620 ***
