Bug 120215 BPS 40 - DE changes
1. all report elements' properties will be overidable with an expression. The binding expression will have access to report parameter, and static BIRT report objects only. 2) DE will provide api to get property binding expression for a given property on a report element handle. It's up to the engine to evaluate the property binding expression when the report gets executed. DE API changes -------------------------- a) DesignElementHandle will support the following two methods. - String (expression) GetPropertyBinding ( propertyName ) - void SetPropertyBinding( propertyName , String (expression) ) // Note get and set property methods are wrapper classes which actually use reportDesignHandle methods to retrive and set the property binding. b) rom.def changes Property bindings contains a list of binding expressions. ReportDesign element will be enhanced to support a new property called. <Property canInherit="false" detailType="propertyBinding" displayNameID="Element.Module.propertyBindings" isList="true" name="propertyBindings" type="structure"/> A new datatype - <Structure name="propertybinding"> <Member name="name" since="2.0" type="name"/> <Member name="id" returnType="any" since="2.0" type="string"/> // Use the unique id used to identify an element. <Member name="value" returnType="string" since="2.0" type="expression"/> </Structure>
model/org.eclipse.birt.report.model/src/org/eclipse/birt/report/model/core/DesignElement.java
* perspective of the design, is when the element is added to the containment
 * hierarchy. Similarly, the definition of deletion, again from the perspective
 * of the design, is when the element is dropped from the containment hierarchy.
 * </dd>
 * 
 * <dd><strong>By pointer </strong></dt>
 * <dd>The design tool itself references elements mostly using Java pointers.
 * That is, once the application finds an element of interest, it simply holds
 * onto it using a pointer.</dd>
 * 
 * <dd><strong>By ID </strong></dt>
 * <dd>The web designer needs a simple way to reference items across calls to
 * the server. None of the above is both simple and consistent. Element IDs
 * provide this service. IDs are valid only within a single design "session". A
 * session is the time between when a design is loaded into memory, and the time
 * that the design is released. IDs are <em>not </em> valid across sessions,
 * and are not persistent. The application must enable IDs by calling
 * {@link org.eclipse.birt.report.model.metadata.MetaDataDictionary#enableElementID}.
 * Call {@link #getID}to get the ID of an element. Call
 * {@link Module#getElementByID}to obtain and element given an element ID.
 * </dd>
 * </dl>
 * 
 * <h3>Element Visitor</h3>
 * 
 * A visitor class is a design pattern that is useful for implementing certain
 * kinds of algorithms that need to "touch" many different elements. One could
 * code the element by adding methods to each element, but doing so is
 * cumbersome, complex, and error-prone. Better is to define a <em>visitor</em>
 * class that has methods for each element. One simply <em>applies</em> the