Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[bpel-dev] Validation and model references.

So I had been studying a bit the insides of the code relating to validation and visual markers.

Markers (IMarker) are created on the resource (ie. bpel file) and suitably created markers will show up in the problem view. The EditParts of the editor are looking for them via a IMarkerHolder. Most of the IMarkerHolder adapters are pointing to BPELUtil.getMarkers() and that's where trail stops. It seems there has to be a way to query markers present on the resource and map them onto the EMF objects that they relate to. In fact, there is an comment on that code to do exactly that ....

If the validator code is using the EMF model, then this is probably trivial since the model object to which the marker belongs could somehow be associated with that marker - via a marker property for example, though I am not sure that is the best practice of doing so.

I am concerned about potential validator code that may not rely on the EMF model. There may be a need to adapt such code to the editor just by the runtime pairings or because it simply exists :-)

A quick way to do this is to run such validator on some format of the model (perhaps DOM tree, perhaps BPEL source) and then read the errors and warnings it produces and map them back to markers that the editor understands. But here lies the problem ....

Since in the EMF model we don't facade the DOM tree nor do we keep any line number information from the source, this mapping to markers cannot be done.

There are 2 ways I can think of that we could rely on to map these externally generated errors onto markers.

1) Line, Col numbers, of the source file. If the validator emitted them and the model knew about them, then we could map the errors to markers and relevant EMF objects that way. 2) XPath. If the validator emitted XPath of the node with the problem, then (if had the DOM facade) we could query it and arrive at the facading DOM node and presumably from there the EMF object.

To be as flexible as possible going forward (1) might be needed. The DOM facade is already on radar, and is scheduled to be done.

Thoughts ?

--
Michal Chmielewski, CMST, Oracle Corp, W:650-506-5952 / M:408-209-9321 "Manuals ?! What manuals ? Son, it's Unix, you just gotta know."


Back to the top