Community
Participate
Working Groups
HighlightRule should reference a Style element instead of having several style properties. With a reference to a defined Style element it would be easier to change the style of hightlight rule just by changing the Style element (which may reside in a library and is used by several reports). The current ROM requires that every report defines it own highlight rule styles.
Good suggestion to support using style for highlight rule.
There are many issues if the highlith rule refer to a sytle element. 1. Actually, the highlight rule style properties are only a sub set of a style properties. For example, the masterPage, mapRule... in style can not be applied to a highlight rule. If the highlight rule refer to a style directly, it needs extra logic to control it. 2. If a highlight rule can refer to a style, that will cause the circularity reference issue because the referenced style also has the highlight rule property. Many constrains need to be added to handle this case. The highlight rule is just a group of some layout properteis. It is not a style. But I can understande the usage proposed in the bug. User defined a style with many properties and wants to use it to highlight sommething. To achieve this, we can provide a function to convert a style properteis to highlight rule. From the UI interface, just like to drag a dataset from data explore to layout to create table. What Model do is just convert the common properties between Style element and highlight rule and apply the property value on the rule.
I think it is a better usage to refer to a style in highlight rule then copy a subset of style properties to high light rule, since when users change the style, they might expect the highlight rule change as well. Is it correct that a lot of report element has the same behavior that style properties is a superset of the element properties? How about let highlight rule only pick the subset of properties it need from the style? Highlight rules in the style probably won't be included in that subset, so it would cause circular reference problem. In fact, it could be a valid usage that highlight rule in a style reference to its parent style to define the formatting properties.
This need to enhance model system to support a strcuture reference to an element, which is not simple and need a good design based on the current system. Schedule to 2.2 and I will give a spec.
Has added this feature in Model part. Need BIRT UI support next.
Model already done this feature implementation, can you close this bug and file a new one for UI?
Need an UI spec or mock up?
We already fixed this bug. We have seperate bug 165624 to trace this feature. Please don't reassign this to GUI. Thanks
question? In the hightlight rule - What happens if a user selects a style "StyleBlue" and then sets a local property font = red. Will the local font property override the style font property. thanks
I believe this is an or condition in the highligh rule. Either use a style or define a style property. In M4 it does not appear to let you set the background color in anything but a style now, which means the highlight rule would be applied last. If you use script say like: this.getStyle().backgroundColor = "Yellow" This is applied after hightlight rules though.
For comments #9, the answer is YES. The color will be "red". Actually, the local property has high priority than values in the referred style. This feature has been supported in Model part. UI has bug 165624 for this feature. Close it.
