This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 155049 - Show error annotations for validation errors automatically
Summary: Show error annotations for validation errors automatically
Status: NEW
Alias: None
Product: xml
Classification: Unclassified
Component: Validation (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: Samaresh Panda
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-12-09 16:27 UTC by Jesse Glick
Modified: 2009-10-22 13:28 UTC (History)
1 user (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2008-12-09 16:27:33 UTC
I'm not sure why I didn't file this years ago; I guess I thought it was so obvious that it must already be planned, yet
it still does not exist. So:

If you have an XML document open in the editor which specifies a DOCTYPE with DTD, or which specifies a namespace and a
corresponding XML Schema is available somehow (possibly via the catalog), the IDE should automatically try to validate
the document in the background as you edit it (after e.g. a 3-sec timeout, like for Java sources). Any validation errors
should show up as error annotations in the gutter, so you can use Alt-ENTER etc. so see them. (Validation can also
produce nonfatal warnings on occasion, which should show up as warnings.)

Documents with no apparent schema should still be checked to see if they are well-formed.

Ideally the box in the corner of the document would also change from green to red in case of problems, and the document
tab would get an error badge, but this is less important.

Basically, you should not need to invoke Check/Validate XML explicitly - if there were any problems, you would be told
right away. This would make it much less likely that people would accidentally introduce invalid XML into their
documents. For example, people routinely edit apichanges.xml in the NB editor, save & commit it, even though the XML is
not even well-formed (much less valid). This would never happen if they got a wavy red underline as soon as they messed
up. It works for Java, why not XML?
Comment 1 Torbjorn Norbye 2008-12-09 20:09:32 UTC
Samaresh, I saw you asked on an alias for pointers on how to implement hints etc. This is probably something you want to use the new Parser API for, it's 
exactly what it's for (it will listen on editor changes, handle threading issues, launch your parser (validator), and let you add tasks which are run when the 
parsing is complete (which in your case would just populate the editor stripe with underlines from the errors accumulated during the parse)