Community
Participate
Working Groups
I've been attempting to add an 'override' icon in the XSL editor's ruler. To do this, I need to add annotations that are not the one of the usual error, warning, info validation annotations (in fact, the override annotation is not even a marker). I had a look at how the JavaEditor adds its override annotations, and it seems it does the following: a) creates an override annotation manager within the doSetInput method of the editor. It passes the manager a reference to its IAnnotationModel so that the manager can create annotations itself. b) adds the override annotation manager as a listener to the editor's reconciling strategy (the manager creates the annotations on the callback it gets when a reconcile finishes) I tried to follow the same pattern for the XSL editor, but hit a snag - the SSE StructuredTextViewerConfiguration getReconciler method is final, so I can't add a listener anywhere to listen to reconciles completing. Now, I did think of adding a listener to a org.eclipse.wst.sse.ui.sourcevalidation IValidator instead (as this is in effect 'listening' to the reconcilver). But the problem with that is that the validator is not being passed any information about which editor is being source validated, so it is not able to get the annotation manager with which to create annotations. So, in summary, it would be great if there were some way to listen to SSE reconcile's completing. However, even with this in place, there is also a further problem: - I have 2 stylesheets S1 and S2 open in editors, and S2 imports S1. - Stylesheet S2 has a template 't1' that overrides template 't1' in stylesheet S1. - I switch to the S1 editor, and change the name of 't1' to 't2' - I switch to the S2 editor, but the override annotation is still there, even though it no longer overrides anything! Now, the java editor does not have this problem. Thats because its reconciler listens to editor activation and forces a reconcile, thereby removing the override annotation. But the SSE reconciler does not listen to editor activation. So, in summary again, it would also be great if SSE reconciler were more like the java one and gets reconciled when editors are activated. For reference, the java reconciler is org.eclipse.jdt.internal.ui.text.JavaReconciler.
Any thoughts on this? Thanks.
Created attachment 142080 [details] proposed patch Might help with testing for bug 281380, too.
Nick any idea if this will make it into 3.2? We have need of it in wst.xsl.
Created attachment 149474 [details] patch I'm not sure if I'm doing something wrong, but with the original patch, my reconciling listeners never were added to the DocumentRegionProcessor. To resolve this, I added the capability to createPartControl after the source viewer is initialized. I also added some clean up to null out the reference to the listeners in the DocumentRegionProcessor's uninstall.
I guess the remaining step is to add an IPartListener to the Reconciler to force reconciling. I guess the thing we'd need to take into account is that we don't *always* want to reconcile, just when something worth causing a forced-reconcile has occurred.
Created attachment 149476 [details] patch
I'm pretty sure I misspelled "coarse" in the comments.
(In reply to comment #5) > I guess the remaining step is to add an IPartListener to the Reconciler to > force reconciling. I guess the thing we'd need to take into account is that we > don't *always* want to reconcile, just when something worth causing a > forced-reconcile has occurred. I think it may be OK to always reconcile. I'm pretty sure this is what the JDT does at least?
From what it looks like, the JDT checks if the Java model has changed on part activation. If it has, it forces a reconcile, otherwise it doesn't.
Created attachment 150321 [details] patch with shell and part activation Here's a shot at a patch with support for shell and part activation. I'd be willing to accept slicker ways to get the editor part fEditor for the part listener.
I don't think an ITextEditor belongs in the text viewer configuration class, nor do I think activation of the editor's shell is really what we're aiming for--shouldn't it be activation of the editor part?
If we're basing functionality on the JDT's reconciler, they have both a part listener and a shell adapter for when the shell is activated again--I guess for the case of alt tabbing and modifying something. If we want, I can just make it for part activation. I agree with your comment about passing the ITextEditor around with the text viewer configuration. I was hoping someone might have a slick way of getting the editor, as I mentioned when I submitted the patch. I'll investigate alternatives.
Created attachment 152754 [details] patch This patch should clean things up a bit. The shell activator has been removed and the configuration no longer has a reference to the editor.
Nitin, what do you think of the changes?
I'd rather the part listener not be in the dirty region processor. It heightens the possibility for the listener to still be referenced in the workbench when the processor's been disposed of. I'd rather see it in the editor part class.
Created attachment 153647 [details] patch with listener in editor Moved the part listener into the StructuredTextEditor and added a public method into the DocumentRegionProcessor to force reconciling.
The only thing I'm not a big fan of are the private inner classes. Main reason is that they make unit testing much more difficult. Also, I see no unit tests to go with this to verify functionality and that particular methods are working as proposed. They also give some idea of how these may be used by adopters if necessary. I know I harp about unit tests, but they make life so much easier in the long run.
Agreed about tests, and we should verify that the arguments (document, annotation model, etc.) are best on #reconciled instead of #aboutToBeReconciled before moving the new interface into a public package (it's more locked down this way).
Also, this and bug 294088 would prompt a minor version bump of sse.ui during M5, which we should announce so that adopters can be ready.
Thanks for the review and discussion. I will put together unit tests for the reconciling listeners in M5 as well as do the minor version bump. I'm using Bug 296761 to track the unit tests.
(In reply to comment #20) > Thanks for the review and discussion. I will put together unit tests for the > reconciling listeners in M5 as well as do the minor version bump. I'm using Bug > 296761 to track the unit tests. Personally, I would have preferred tests to go with the code before this was resolved.
