Home » Modeling » TMF (Xtext) » Triggering "re-validation" of non-dirty resource
Triggering "re-validation" of non-dirty resource [message #1724435] |
Tue, 23 February 2016 22:49 |
Larry LeBron Messages: 124 Registered: October 2015 |
Senior Member |
|
|
In my language, I track state which affects the validity of EObjects project-wide.
For example, this state tracks the nature of name uses across resources. If certain conditions are met, an object will become "valid". Similarly, it may become "invalid".
However, this state is only queried when my @Check methods are actually run by the validation system.
Currently, when I use my language, the validator only runs when I call a clean, or when a resource becomes dirty.
However, for my case, I want a resource to be re-validated if this underlying state changes, causing the proper error UI elements (e.g. red x's) to be added to the resource. I see this happening in Xtend, so I know it must be possible.
I have experimented with manually calling the validator via Diagnostician.INSTANCE.validate, IResourceValidator.validate, IResourceUIValidatorExtension.updateValidationMarkers() and by creating my own delta and calling IMarkerUpdater.updateMarkers. These all run the validator, but none cause the error UI elements to update properly the way Xtend does. (Discussed here)
Would it be better to instead somehow mark the affected resource as dirty? I'm looking into how to do that, but haven't yet seen how to instantiate an IDirtyResource object. Or, is there another recommended way?
EDIT for clarity:
Specifically, the UI error elements I'm talking about are:
- Red x icon on project, src folder, package and file in package explorer
- Red x icon in left margin of editor window
- Red x icon in bottom left of file editor tab
- Red highlight under editor text
- Error description in problems view
Thanks!
[Updated on: Wed, 24 February 2016 06:13] Report message to a moderator
|
|
| | | |
Re: Triggering "re-validation" of non-dirty resource [message #1724947 is a reply to message #1724918] |
Sat, 27 February 2016 17:10 |
Larry LeBron Messages: 124 Registered: October 2015 |
Senior Member |
|
|
I did some debugging, and, as Jan explained, during the build process after a delta in a given resource, Xtext goes through a process where it determines which other resources are "affected" by this change and therefore need to be rebuilt/revalidated.
This is great because, as Jan mentioned, this does not require an additional validation phase.
Specifically, this happens in:
DefaultResourceDescriptionManager.isAffected(Collection<Delta> deltas, IResourceDescription candidate, IResourceDescriptions context)
In this method, the deltas are the changes, and the "candidate" is another resource to consider as affected.
I added and bound a custom ResourceDescriptionManager with a hook into this method. Specifically, since my project uses XBase, extended DerivedStateAwareResourceDescriptionManager for this.
The binding looks like:
override Class<? extends IResourceDescription.Manager> bindIResourceDescription$Manager() {
return MyDSLResourceDescriptionManager;
}
In my custom implementation, I added an override for the isAffected method, with a special check up top to query the side-indexing I initially referred to. If this check fails then I default to super.isAffected for now.
Basically, this is helping me handle a more complex cross-referencing system which allows one-to-many cross references. The updating of my side index happens before the build process begins querying for isAffected, so I'm just statically tracking all resource URIs which have been affected since the last resource build. So, when I get to this stage, I can just check if the "candidate's" uri is in that set. If so, I flag it as affected and it is rebuilt.
So far, it's looking good!
I have noticed a bit of odd behavior where, during the isAffected query cycle, the same candidate might be queried twice. For example, this was happening with my Xbase project because both the resource change and the generated class change were being treated as deltas. At first, I was removing my candidate URIs from the set upon first detection, assuming that flagging them as "affected" that first time was enough. But, if, during a second isAffected query they were no longer flagged as affected, I found that the resource wasn't being processed as I desired. So, now I just leave them in the set for the whole isAffected cycle. That seems to be doing the trick.
[Updated on: Sat, 27 February 2016 17:15] Report message to a moderator
|
|
| | |
Goto Forum:
Current Time: Fri Mar 29 14:19:09 GMT 2024
Powered by FUDForum. Page generated in 0.02667 seconds
|