Summary: | [api] Add life-cycle support to document | ||
---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Anton Leherbauer <aleherb+eclipse> |
Component: | Text | Assignee: | Platform-Text-Inbox <platform-text-inbox> |
Status: | ASSIGNED --- | QA Contact: | |
Severity: | enhancement | ||
Priority: | P3 | CC: | eclipse, thatnitind |
Version: | 3.1 | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | Windows XP | ||
Whiteboard: | |||
Bug Depends on: | |||
Bug Blocks: | 189474 |
Description
Anton Leherbauer
2006-02-22 06:10:37 EST
>s a concrete example, we have an IDocument implementation which uses temporary
>files as underlying text buffer.
Couldn't you write your own file buffer that handles this and use it instead of the document where appropriate?
Hm, I probably don't quite get your point, but it need be an IDocument. The document is created by an IDocumentFactory which is registered for certain file types. Document instances created this way are simply out of control. It is possible to have a listener observe the disposal of the ITextFileBuffer and dispose the document/delete the temporary files in that same moment, but it appears that this is too aggressive, because the document might still be used. Note that IDocumentFactory has been deprecated in 3.2. Perhaps I am missing something - but the IDocumentProvider protocol already defines a life-cycle (connect / disconnect) and both AbstractDocumentProvider and TextFileDocumentProvider implement a reference counting scheme. Couldn't you use this to do what you want? Yes, I did this and ran into the problem that the document was used after the document provider refcount went to 0. See also bug #65211, esp. comment #2: > Please be aware that deconstructing the document on disconnect is dangerous. > IDocumentProvider does not specify that a document once obtained from the > provider may become invalid without notification. The same is true for > IDocument. IDocument does not define a live cycle or predicates that tell a > client whether a document is deconstructed or disposed. Thus, any code that > does not care about the life cycle of specific IDocument implementations is > valid code. The changes I made can not be expected in general. It's just > courtesy. This is certainly true and it clearly expresses what is missing: a life-cycle for IDocument. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. |