Convertor API

$Revision: 1.2 $
Changes: available in CVS
Issue: 34671

As written on Settings Overview page the Convertor API is redesigned core/settings module with these major changes:
  • implementation does not uses Datasystems
  • it has simplified registration
  • it simplifies existing Properties convertor and encourages its usage
  • it provides other convertors and deprecates existing ones
  • auto saving was cancelled
The final module with public API, documentation, unit tests and examples can be found in main trunk as module openide/convertor. The JavaDoc is here.

Usecases

List of usecases for which the Convertor API was designed.

U1: user has instance of Car class and needs to persist it

Write convertor for the Car class, make up unique XML namespace and register convertor for that XML namespace and Car class.

U2: user has instance of Car class and needs to persist it. User does not want to write own convertor.

Use SimplyConvertible way to persist your object. Make up unique XML namespace, implement SimplyConvertible interface on Car class and register Car class and the XML namespace as simply convertible.

U3: there is base class Car for which exists convertor. User created SkodaCar which extends Car and which must be persisted.

There are two options:
  • if the Car implements SimplyConvertible then the SkodaCar can make up unique XML namespace, override SimplyConvertible methods on SkodaCar (consider calling super implementation) and register SkodaCar and the XML namespace as simply convertible.
  • second option is the same answer as in U1. If the Car base class has state which must be persisted then its SkodaCar class job to do that. Convertor API does not provide any special support for that. The Car class must be designed to enable that.

U4: there is base class Car for which exists convertor. User created SpecialCar which extends Car and which must be persisted. SpecialCar does not add any state variables.

This usecase is similar to U3 with difference that base convertor defined for Car could be used directly for SpecialCar. There is no optimization for this usecase. See U3 for the asnwer.

U5: user has Car class instances in version V1 of product. In version V2 of the product the Car class is extended with several new state variables. User want to be able to read V1 persisted instance in V2 product, but want to convert them to V2 version of Car.

Several options:
  • if user knows about all persisted V1 instances they can be converted to new V2 format or deleted during the upgrade of product to V2 version
  • write V2 convertor for the V2 Car class, make up unique V2 XML namespace and register convertor for that XML namespace and Car class. Modify V1 convertor to not write Car instances anymore (will be done by V2 convertor) and modify it to be able to create V2 Car instances from the V1 persisted data.

U6: user has instance of Car class and needs to persist it. The Car class state variables are four instances of Wheel class . The Wheel class has its own convertor defined by different project.

See U1 for the answer. For persistence of embedded objects use Convertor API.

Misc Links

  • discussions about Convertor API on nbdev: 1, 2

Project Features

About this Project

openide was started in November 2009, is owned by Antonin Nebuzelsky, and has 78 members.
By use of this website, you agree to the NetBeans Policies and Terms of Use (revision 20160708.bf2ac18). © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo
 
 
Close
loading
Please Confirm
Close