Bug 149251 Inconsistent Handling of a Non-inheritable ROM Property
For a ROM property defined to be non-inheritable, an empty string property value should be consistently handled as an empty string, not as null. For example, an oda.dataSource extension defines a data source property with canInherit=false. When a oda-data-source handle get saved in a report design, it correctly includes the tag for such property, even when an empty string value is specified. <oda-data-source extensionID="my.oda.plugin" name="my Data Source" id="24"> ... <property name="ApplicationServer"></property> </oda-data-source> However, later when using the DE API to read its property value, a null is returned. Then when the report design is subsequently saved, the property tag is lost. Expects that an empty string value of a non-inhertiable property should be preserved.
model/org.eclipse.birt.report.model/src/org/eclipse/birt/report/model/metadata/ElementDefn.java
import org.eclipse.birt.report.model.api.util.StringUtil;
import org.eclipse.birt.report.model.api.validators.StyleReferenceValidator;
import org.eclipse.birt.report.model.api.validators.UnsupportedElementValidator;
import org.eclipse.birt.report.model.core.DesignElement;
import org.eclipse.birt.report.model.core.StyledElement;
import org.eclipse.birt.report.model.elements.interfaces.IStyleModel;
import org.eclipse.birt.report.model.validators.AbstractSemanticValidator;
/**
 * Describes a report element. This class represents "meta-data" about an
 * element. This class does not represent the element itself. Rather, it
 * describes a "class" of elements. The definition provides information about
 * the set of valid properties, their validation rules, and more.
 * <p>
 * To understand this class, it helps to understand some concepts behind the
 * design of the model.
 * 
 * <h3>Meta-data vs. Elements</h3>
 * 
 * A design is made up of <em>elements</em>. BIRT defines a fixed-set of
 * <em>element types</em> such as List or Data or Image. The user defines the
 * elements in the report. However, element types are defined by the development
 * team and are fixed for any given release of the product. The class
 * DesignElement (and its subclasses) describe the elements that users create.
 * The class ElementDefn describes element types.
 * <p>
 * Elements are part of a design, and each design has its own set of elements
 * depending on what the user wants to build. Element types, however, are the
 * same for all open designs. Hence, type information is stored in a shared
 * <em>data dictionary</em>. Every concrete element type has a Java class
 * that implements the element.