Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 26076 - [api] Provide location context to convertors
[api] Provide location context to convertors
Status: VERIFIED FIXED
Product: platform
Classification: Unclassified
Component: -- Other --
3.x
All All
: P1 (vote)
: 3.x
Assigned To: Jan Pokorsky
issues@platform
: API
Depends on: 26275
Blocks: 23289
  Show dependency treegraph
 
Reported: 2002-07-29 11:23 UTC by Jan Pokorsky
Modified: 2008-12-22 19:47 UTC (History)
4 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo