In the Fishbolt data model, a data field is presented by the IDataField
interface. Its generic parameter T
defines the type of a data field value. The IDataField
interface declares setValue
methods which are used to set and get the value of a data field, respectively. For example, a data field with an Integer
value is presented by the IDataField
interface whose setter and getter methods are used to set and get an Integer
The life cycle of an IDataField
instance is the same as the life cycle of its enclosing IDataObject
instance. The value of a data field can be changed many times during its life cycle. But the data field instance itself will remain the same.
A data field is declared in a data object as a constant, for example:
final static FieldDeclaration name = new FieldDeclaration();
Assuming that our data object is called Department
, we can make a static reference to the data field in our code using this constant: Department.name
. The constant declaration defines existence of the data field (IDataField
instance) in the data object instance of the corresponding type. The constant is used to access the value of the corresponding data field. The base data object interface called IDataObject
declares the following method:
IDataField getDataField(FieldDeclarationT> declaration);
The code to access the value of the data field presented by the name
constant of the Department
object is shown below:
Department d = ...;
IDataField dataField = d.getDataField(Depatment.name);
String name = dataField.getValue();
Or you can use a shortcut method of the ModelUtil
class to get the data field value as shown below:
String name = ModelUtil.getValue(d,Depatment.name);
In contrast to the Fishbolt data model, the Java beans-based approach doesn’t involve a separate class for a Java bean property. In other words, Java beans do not provide an object that wraps up a property value and has the same life cycle as a bean instance.
Such an object may be implicitly present in developer’s mind as a property name – Java bean instance
pair. But the presence of such an object in developer’s mind doesn’t allow the developer to make a reference to this object in program code.
Of course, the developer can easily create a class defining the property name – Java bean instance
pair. But there is a price to pay for it because such a class will make it much more expensive to change the property name or to delete the property. In program code, it's impossible to make a reference to a bean property in such a way that reference-related errors occurring as a result of deleting the property or changing its name can be detected at compile-time.
(The errors became apparent only at runtime.) The reason behind the problem is that a bean property can be only referenced using a String
that specifies the name of the property.
You may ask: is an object-wrapper for a field value really needed? A strong argument against effectiveness of these wrappers is that they require extra memory comparing with Java beans. But the advantages of the Fishbolt data model outweigh this shortcoming. The model provides a self-descriptive and simple way of presenting a data unit (i.e. a field value) and allows users to create a variety of reusable components for data handling. With the model, it's possible to make a reference (via a static constant) to a data field before an instance of its enclosing data object is created (constants like Depatment.name
don’t require for an instance of a data object to exist). This possibility allows creating whole systems that will be configured by declaring a set of constants, with correctness of references in program code being checked at compile-time.
As an example of such a system, see the "User interface for the data model in Eclipse IDE" project (http://fishbolt.org/eclipse/org.fishbolt.model.eclipse/doc/plugin.article.en.html
). In this project, data is bound to components of the user interface in a declarative way as described above.