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.
Summary: | [2004-04-29] Create API for Annotation providers | ||
---|---|---|---|
Product: | platform | Reporter: | _ rkubacki <rkubacki> |
Component: | Text | Assignee: | Petr Nejedly <pnejedly> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | apireviews, dkonecny, jtulach, pnejedly, ttran |
Priority: | P2 | Keywords: | API, API_REVIEW_FAST, PERFORMANCE |
Version: | 3.x | ||
Hardware: | PC | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 41192 | ||
Attachments: |
AnnotationProvider source with Javadoc
Current implementation Sorry, the previous patch was incomplete, here is complete one. Final patch |
Description
_ rkubacki
2004-03-25 11:30:03 UTC
Possible solution would be to use something like tasklist has: an interface registered in global lookup that would be called when an editor is about to open to add annotations: interface org.openide.text.AnnotationProvider { public void annotate (Line.Set set, Lookup context); } which would be called from CloneableEditorSupport when it wants to open CloneableEditor component with its Line.Set and lookup passed to its constructor. We'll need this to allow effective breakpoints persistency and so on. Yarda's api is nice and flexible, but what about the mandatory lookup content? DataEditorSupport would pass DataObject, which is enough for e.g. debugger to provide its annotations, but have uncertain future. What about providing FileObject or URI of the edited resource instead? That would fit more nicely into new BS and provide more space for future evolution. Already have some working code locally... Sorry, but because of THE process, I can't commit it that fast... can you describe your solution here? And attach the diff review info: *) Issue description: see above *) Target milestone: Promo-D *) Blocks: issue 41192 *) Change: API: Introduce new callback interface as described in comment #2. Change: On opening of an editor, find all implementations of the interface in the default lookup and call them. Their expected behaviour is to check the context and then possibly attach some annotations to the provided Line.Set *) Changed interfaces: Introduced new interface AnnotationProvider *) Javadoc and stability: See the attached source file, the API is stable Created attachment 14473 [details]
AnnotationProvider source with Javadoc
Created attachment 14474 [details]
Current implementation
1) I not it better to provide some more general api? Something like document opened? 2) Lookup as a parameter - why? Can it contain something more than FileObject? But it looks like it covers my requirements. Thanks. CES.java should perhaps (statically) cache the Lookup.Result rather than call it for every file that it opened. Otherwise looks fine to me. Created attachment 14525 [details]
Sorry, the previous patch was incomplete, here is complete one.
> 1) I not it better to provide some more general api? Something like > document opened? No. Request for annotations may be disconnected from document opening. > 2) Lookup as a parameter - why? Can it contain something more than > FileObject? Generally, doesn't matter to you. You'll lookup the FileObject there and act accordingly to the one found. If you found nothing, the request is irrelevant to you, just ignore it (that is, in future, more things than FO/DO based files can be made annotatable, so they may provide different type in the context, e.g. URI) > CES.java should perhaps (statically) cache the Lookup.Result rather > than call it for every file that it opened. Possible, but I don't expect high frequency of the call. Even during startup with more opened editors, only the visible one is annotated, the rest is annotated as you switch to them. (Note: This is behavioral detail of current WS implementation, it may change, but we can add caching later, if proven needed) I am fine with everything except missing tests. Without them the commit is too dangerous and it will not be possible to watch regression or made improvememts. Possible test include: register one or two providers in lookup, make cloneable editor support, call its open method, make sure that the providers are called and they receive lookup with appropriate content, that they can attach annotations to the Line.Set and that the annotation stay are attached to the Line.Set after the document is closed. OK, I'm going to commit the implementation with tests tomorrow. I'll attach the final diff... Created attachment 14624 [details]
Final patch
Nice except on thing: testDataObjectMoveFiresLookupEventAndChangesContentOfLookup is missing I guess. Integrated, with additional tests openide/openide-spec-vers.properties,v1.138 openide/api/doc/changes/apichanges.xml,v1.193 openide/src/org/openide/text/AnnotationProvider.java,v1.1 openide/src/org/openide/text/CloneableEditor.java,v1.70 openide/src/org/openide/text/CloneableEditorSupport.java,v1.121 openide/loaders/src/org/openide/text/DataEditorSupport.java,v1.15 openide/test/unit/src/org/openide/text/AnnotationProviderTest.java,v1.1 |