Filter validation errors by location

[peterls]

I've got a plugin that vetoes document save on validation errors beyond a certain severity, which is working fine. Now a new requirement has come in to completely ignore (for veto purposes) errors that happen within a certain element.

Imagine something like <user-content>, in which users can sometimes include content that doesn't pass DTD validation, but we still want to save it. (To be fixed in a later editing session.) Other parts of the document however are more strictly checked and we block saving until those errors are fixed.

My problem is that with DTD validation I only get line and column info in DocumentPositionedInfo, which I'd need to use to match up with AuthorNodes.

There's two ways I see to resolve this: find AuthorNodes by line/column location or get line/column info for an AuthorNode, but I can't seem to find anything that would do either.

Have you got any ideas of how to do this efficiently? (I can in theory grab the entire content via WSEditor.getContentReader(), parse it and count the lines and columns, but I'd want to avoid it if possible.)

[Radu]

Hi Peter,

This API ro.sync.exml.workspace.api.editor.page.WSTextBasedEditorPage.getStartEndOffsets(DocumentPositionedInfo) should help, it should return offsets mapped directly in the Author contents and after this you can use the "AuthorDocumentController" to get the node at offset.
By the way, for what Oxygen version are you customizing? We are still getting unhandled errors from people on your side using Oxygen 16.1 and those errors might stem from your plugin calling ro.sync.ecss.extensions.api.node.AuthorElement.setAttribute(String, AttrValue) with a null attribute value.

Regards,
Radu

[peterls]

Thank you, I'll have a look at that page class. Is it available in Author mode though? At the moment I'm calling StandalonePluginWorkspace.getEditorAccess(new URL(problem.getSystemID()), StandalonePluginWorkspace.MAIN_EDITING_AREA);, and if I call getCurrentPage() on that, it returns a WSAuthorEditorPage, which is what I would expect given that we're in Author mode.

As for versions, different systems use different versions, the one I'm looking at uses 18, but there are ones that still use 16.1, yes. I'll take a look at those too as soon as I can.

[peterls]

Thank you, I'll have a look at that page class. Is it available in Author mode though? At the moment I'm calling StandalonePluginWorkspace.getEditorAccess(new URL(problem.getSystemID()), StandalonePluginWorkspace.MAIN_EDITING_AREA);, and if I call getCurrentPage() on that, it returns a WSAuthorEditorPage, which is what I would expect given that we're in Author mode.

As for versions, different systems use different versions, the one I'm looking at uses 18, but there are ones that still use 16.1, yes. I'll take a look at those too as soon as I can.

Never mind, I've just realised that WSAuthorEditorPage extends WSTextBasedEditorPage.