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.

Bug 41345 - [2004-04-29] Create API for Annotation providers
Summary: [2004-04-29] Create API for Annotation providers
Alias: None
Product: platform
Classification: Unclassified
Component: Text (show other bugs)
Version: 3.x
Hardware: PC All
: P2 blocker (vote)
Assignee: Petr Nejedly
Depends on:
Blocks: 41192
  Show dependency tree
Reported: 2004-03-25 11:30 UTC by _ rkubacki
Modified: 2008-12-22 16:39 UTC (History)
5 users (show)

See Also:
Exception Reporter:

AnnotationProvider source with Javadoc (1.19 KB, text/plain)
2004-04-20 10:31 UTC, Petr Nejedly
Current implementation (1.59 KB, patch)
2004-04-20 10:39 UTC, Petr Nejedly
Details | Diff
Sorry, the previous patch was incomplete, here is complete one. (2.68 KB, patch)
2004-04-22 13:20 UTC, Petr Nejedly
Details | Diff
Final patch (23.40 KB, patch)
2004-04-29 16:21 UTC, Petr Nejedly
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description _ rkubacki 2004-03-25 11:30:03 UTC
Annotations should be created on demand by some
providers when there is a need for them rather
than actively registered in advance even in cases
when noone needs them. 

The goal is to avoid cases like breakpoint
deserialization performed during IDE startup in
debugger in order to restore their annotations in
editor. Editor can ask debugger (provider) to
attach annotations when it creates Annotatable object.
Comment 1 Jaroslav Tulach 2004-03-30 06:09:25 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.
Comment 2 Petr Nejedly 2004-04-14 15:31:21 UTC
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
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. 
Comment 3 Petr Nejedly 2004-04-19 20:51:54 UTC
Already have some working code locally...
Comment 4 Petr Nejedly 2004-04-20 10:07:40 UTC
Sorry, but because of THE process, I can't commit it that fast...
Comment 5 _ ttran 2004-04-20 10:10:09 UTC
can you describe your solution here?  And attach the diff
Comment 6 Petr Nejedly 2004-04-20 10:26:13 UTC
review info:
*) Issue description: see above
*) Target milestone: Promo-D
*) Blocks: issue 41192
*) Change:
  Introduce new callback interface as described in comment #2.
  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
Comment 7 Petr Nejedly 2004-04-20 10:31:16 UTC
Created attachment 14473 [details]
AnnotationProvider source with Javadoc
Comment 8 Petr Nejedly 2004-04-20 10:39:23 UTC
Created attachment 14474 [details]
Current implementation
Comment 9 Jan Jancura 2004-04-21 16:56:26 UTC
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

But it looks like it covers my requirements. Thanks.
Comment 10 Jesse Glick 2004-04-21 19:50:55 UTC should perhaps (statically) cache the Lookup.Result rather
than call it for every file that it opened.

Otherwise looks fine to me.
Comment 11 Petr Nejedly 2004-04-22 13:20:03 UTC
Created attachment 14525 [details]
Sorry, the previous patch was incomplete, here is complete one.
Comment 12 Petr Nejedly 2004-04-22 13:42:31 UTC
> 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)

> 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)
Comment 13 Jaroslav Tulach 2004-04-23 17:53:02 UTC
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.
Comment 14 Petr Nejedly 2004-04-29 16:18:12 UTC
OK, I'm going to commit the implementation with tests tomorrow.
I'll attach the final diff...
Comment 15 Petr Nejedly 2004-04-29 16:21:41 UTC
Created attachment 14624 [details]
Final patch
Comment 16 Jaroslav Tulach 2004-04-29 17:12:38 UTC
Nice except on thing:
testDataObjectMoveFiresLookupEventAndChangesContentOfLookup is missing
I guess.
Comment 17 Petr Nejedly 2004-04-30 15:33:43 UTC
Integrated, with additional tests