Bugzilla – Full Text Bug Listing
| Summary: | Exception when set display field for cube and preview[1101] | ||||||
|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Liwen Chen <lchen> | ||||
| Component: | BIRT | Assignee: | Chen Chao <cchen> | ||||
| Status: | CLOSED FIXED | QA Contact: | |||||
| Severity: | major | ||||||
| Priority: | P3 | CC: | dmichonneau, wenfeng.fwd, xxue | ||||
| Version: | 2.2.0 | Keywords: | plan | ||||
| Target Milestone: | 2.2.1 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Liwen Chen
Created attachment 69918 [details]
report design
The display name should be an expression. Reassign to GUI team I can't understand the display name should be a expression. Could you provide more details?What's the reason we have the display name of other items as string but need it as expression this time? According to MODEL, the display name is an expression instead of string. So if user set display name as row["a"] + row["b"], we also need support it. please verify if the display name of xtab is an expression or a constant string. If it is a constant string, please fix it in ROM and re-assign back. otherwise, please re-assign it to UI. The displayName of xtab view is expression type. This was discussed at the beginning design time. The reason is the displayName actually can refer to another column and display the value depends on different condition user gave out. Let me know how can GUI know the input is a string or expression. This is not a news that we assume GUI can guess the input of user. I just don't know how to guess it!. There is benefit for performance and usability to support the distinction of constant string or expr in model. There is also request to support other script language, so suggest to add a property of an enumeration of scripting type in model for expression value properties. By default, the script type is constant string, We can skip the type property for constant string to be less verbose in the report XML. We can only add a script Type property if the expression is indeed a script. UI will need a drop down box next to all expression input box to let user select the script type between string, and javaScript replacing the "Fx" button. When user select one of the script, we can pop up the script editor for that script type. comments? David M. suggest to keep the fx button, since the drop down list will not be obvious to invoke the expression builder once the scriping language is selected. Another suggestion is to have an scripting extension point so that user can plugin their scripting editor and scripting engine at report generation step. I agree that BIRT expressions should have an associated script-type property. For now the type will be Javascript or Constant. The goal is to eventually develop extension points so that externally defined scripting syntax and calculation engine can be plugged into BIRT. As we plan to make the changes discussed so far later For the original issue logged in the bug where the exception is thrown, I suggest we make the following change - For level Display Name, UI continues to show list of data set field names. Example Country, CountryCode, State, City - When user selects one of the items in the list example CountryCode, UI stores in report design as datasetRow[“CountryCode”] This is consistent with other display field of type expression (example cascading parameter) Did UI fixed the original exception? if so, please defer to 2.2.1 for the enh of script type. Fixed it. Defer to 2.2.1 for further enhancement. Currently we just need to make this consistent with other expression type properties, e.g. editable and has an fx button. Fixed it. Verify in build 2.2.1.v200707270630 |