Although not really necessary for NetBeans IDE, it is beneficial for NetBeans Platform users to have an option of
using JavaBeans Archiver for storing content of their .settings files. Please provide a simple annotation to mark
classes eligible for marshaling via XMLEncoder and reading via XMLDecoder.
Created attachment 85587 [details]
[JG01] While this seems harmless, shouldn't new code be written using NbPreferences rather than the old *.settings
infrastructure? What is the use case?
[JG02] XMLBeanConvertor.read should not make assumptions about the line-by-line format of its input.
[JG03] Typo: ignoreProperites
[JG04] EA_PREVENT_STORING should accept only Boolean, not String.
Re. JG01: preferences are good for storing own private settings, not really good for complex inter-module
communications. For that we are relying on Lookup.getDefault() or Lookups.forPath(...) and either .instance
or .settings or .xml registrations. .instance objects are immutable. To accept .xml objects one needs to write own
Environment.Provider (fuj!) and .settings used to have the old horrible serialdata format. There is now more
comfortable option of using @ConvertAsProperties, but I can imagine some modules or platform users to benefit from
more automatic and more standard @ConvertAsJavaBean method.
Created attachment 85743 [details]
Simplified patch addressing Jesse's comments
BTW be sure to publish the new DTD on netbeans.org (use www/www/dtds/ in CVS).
OK, will do tomorrow.
Checking in xml-beans-1_0.dtd;
/shared/data/ccvs/repository/www/www/dtds/xml-beans-1_0.dtd,v <-- xml-beans-1_0.dtd
initial revision: 1.1
Integrated into 'main-golden', will be available in build *200908061401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Jaroslav Tulach <email@example.com>
Log: #169620: @ConvertAsjavaBean to support JavaBeans Archiver format
I'm putting together some release notes on platform changes in 6.8 for Tori, and trying to figure out how one uses
@ConvertAsJavaBean, and I am confused:
- If the annotation allowed you to specify SFS path(s?), I could imagine this generates a layer entry and flags that,
if something gets the instance, the listening code will kick in and the automatic saving will too. But there is no such
- Where does the instance of the object first come from? I still need a .instance file in the layer?
- Since the retention is SOURCE...
- How is it communicated to the rest of the system that this automatic listening/saving functionality should be used?
- How does the system know an instance was created, so it can listen on it?
- How does the system know where to save it?
Could you walk me through a use-case?
The first instance could be made by InstanceDataObject.create with an object of the right class, or you could have a
*.settings file using the archiver format (specifying "-//NetBeans//DTD XML beans 1.0//EN" as public ID) in your layer
for an initial instance.
The annotation retention can be SOURCE because, like all NB annotations, it is processed during compilation into a less
friendly registration in the defining module's generated XML layer.
The system does not know where to save new objects, or that new objects have been created. Instead, after _reading_ an
object from a file (possibly just created using IDO.create), a PCL is attached and any events cause the object to be
written back to the same file. The same is true of a *.settings file in any format, including the old hex serialization
format. The system does know what format to use for a particular object class, because that is what you have registered.
BTW Geertjan blogged about @CAJB with a complete example.