Convertor API
$Revision: 1.6 $
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
