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
* <p>
 * <ul>
 * <li>The {@link #container}member that caches a pointer to the container
 * element.</li>
 * <li>The {@link #getContainer}method to get the container element.</li>
 * <li>The {@link #setContainer}method to set the container element.</li>
 * <li>The {@link #getSlot}method returns a slot within a container.
 * <li>The {@link ContainerSlot},{@link SingleElementSlot}and
 * {@link MultiElementSlot}classes that represent slots.</li>
 * </ul>
 * 
 * <h3>Change Notification</h3>
 * 
 * Any given element may be "visualized" in multiple places in the user
 * interface. If the user changes the element, all the affected parts of the UI
 * must be updated. The notification system is responsible for these updates.
 * <p>
 * The notification system allows any number of {@link Listener}objects to
 * subscribe to receive change notifications for an element. Notifications are
 * sent for each change using subclasses of the {@link NotificationEvent}class.
 * See these two classes for more details.
 * <p>
 * Note: subscribing and unsubscribing listeners is the only mutator operation
 * that the application can (and should) do without the use of a command.
 * <p>
 * Members and classes in the notification system include:
 * <p>
 * <ul>
 * <li>The {@link #listeners}member holds the list of subscribed listeners.
 * </li>