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 26076

Summary: [api] Provide location context to convertors
Product: platform Reporter: Jan Pokorsky <jpokorsky>
Component: -- Other --Assignee: Jan Pokorsky <jpokorsky>
Status: VERIFIED FIXED    
Severity: blocker CC: jtulach, rmatous, sdedic, vstejskal
Priority: P1 Keywords: API
Version: 3.x   
Hardware: All   
OS: All   
Issue Type: ENHANCEMENT Exception Reporter:
Bug Depends on: 26275    
Bug Blocks: 23289    

Description Jan Pokorsky 2002-07-29 11:23:34 UTC
Motivation:
In some cases it is necessary to obtain info about the location of a persisted setting during 
reading or writing operations.

Use case: 
To properly resolve urls peristed in setting that are shared via vcs. It is necessary to find out a 
proper reference resolver (e.g. project's one) and the file location can be the only way.

Solution:
I would propose to add 2 methods to Convertor class 
(http://www.netbeans.org/download/dev/javadoc/SettingsAPIs/org/netbeans/spi/settings/Con
vertor.html):

public Object read (java.io.Reader r, Lookup env) throws IOException, ClassNotFoundException
public void write (java.io.Writer w, Object inst, Lookup env) throws IOException

The settings framework would provide setting's FileObject via env. These methods would 
delegate to current read/write as default impl.

Why Lookup: an api client should not be encourage or tempted to use the passed FileObject 
for storing/reading instead of Writer/Reader passed by the framework.

Issues:
What should be provided when a new .settings file is created. Now the InstanceDataObject 
writes a content to a memory buffer firstly to check the write operation is successful and to 
prevent early access to incomplete .settings file.
Comment 1 Jaroslav Tulach 2002-08-05 09:29:09 UTC
I have problems with adding the Lookup to the method signature. I do
not like such style, also it duplicates the amount of methods in the
class. Also I know that you plan to introduce DOMConvertor with
additional methods and those would be duplicated too. 

So instead of that I suggest a protected static method for that: 
static Lookup findContext ();
or with one argument
static Lookup findContext (Reader);
static Lookup findContext (Writer);
these methods could be called from the read/write methods of
Convertors and returned the associated context (or Lookup.EMPTY).

Question is how to find the right lookup when in read/write method.
For case of Reader/Writer it should be easy, the both could implement
Lookup.Provider interface (yet to be done, but planned). For the
non-argument method, there would have to be a method 
static void executeInContext (Runnable, Lookup);

If the findContext (Reader/Writer) seems acceptable please add
dependency to issue 26275
Comment 2 Jan Pokorsky 2002-08-05 10:47:28 UTC
I like this way to prevent duplication of methods.

findContext(Reader/Writer) - seems acceptable to me.
Due to proposed DOMConvertor there should be also 
findContext(Element/Document).

It is 4 static methods findContext. It is pretty much. So I tend to 
introduce just findContext(Object) or findContext(). But 
findContext(Object) seems to be too confusing.
Comment 3 Jan Pokorsky 2002-08-05 13:58:43 UTC
target milestone -> 4.0
Comment 4 Vitezslav Stejskal 2002-08-15 12:09:27 UTC
Any progress on this issue? There is more and more code in projects which deserves new convertors 
framework, but without having this resolved we can't use it. (e.g. iussue #26436, issue #23289)
Comment 5 Jan Pokorsky 2002-08-20 15:27:32 UTC
Yes, we agreed offline on introducing
protected static Lookup Convertor.findContext(Reader)
protected static Lookup Convertor.findContext(Writer)
protected static Lookup DOMConvertor.findContext(Document)
protected static Lookup DOMConvertor.findContext(Element)

and Lookup.Provider interface (issue #26275).
So I am going to implement it ASAP.
Comment 6 Jan Pokorsky 2002-09-03 19:53:11 UTC
protected static Lookup DOMConvertor.findContext(Element)
was skipped. It is replacable with
DOMConvertor.findContext(element.getOwnerDocument())

Implemented in:

/cvs/core/settings/src/org/netbeans/spi/settings/Convertor.java
new revision: 1.3; previous revision: 1.2

/cvs/core/settings/src/org/netbeans/spi/settings/DOMConvertor.java
new revision: 1.3; previous revision: 1.2

/cvs/core/settings/src/org/netbeans/modules/settings/ContextProvider.j
ava
initial revision: 1.1

/cvs/core/settings/src/org/netbeans/modules/settings/InstanceProvider.
java
new revision: 1.4; previous revision: 1.3

/cvs/core/settings/src/org/netbeans/modules/settings/SaveSupport.java
new revision: 1.6; previous revision: 1.5

/cvs/openide/src/org/openide/loaders/InstanceDataObject.java
new revision: 1.131; previous revision: 1.130

/cvs/core/settings/manifest.mf
new revision: 1.4; previous revision: 1.3

/cvs/core/settings/api/doc/changes/apichanges.xml
new revision: 1.2; previous revision: 1.1
Comment 7 Jan Pokorsky 2003-07-15 14:39:42 UTC
verified