Bugzilla – Full Text Bug Listing
| Summary: | DataSource Connection Profile Property Binding Not Tested at Design Time Open | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Scott Rosenbaum <scottr> |
| Component: | BIRT | Assignee: | Linda Chan <lchan> |
| Status: | CLOSED WORKSFORME | QA Contact: | Tianli Zhang <tzhang> |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | lchan, lzhu, mwu, wenfeng.fwd |
| Version: | unspecified | Keywords: | plan |
| Target Milestone: | Future | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Scott Rosenbaum
Wenfeng has suggested that the DataSet editor should have the ability to over-writed the DataSource properties as a better way to address this issue. Hi Scott, The behavior you described is indeed working as intended. The property binding only will be used at runtime( when running the report design ).Thus at runtime, the property values defined in its content take precedence over corresponding property values assigned within the report design as you expected. But at design time, we will never use property binding. Thanks Mingxia I want to change the behavior. It is my opinion, backed up by Wenfeng, that the DataSet should be checking the parameter values at design time when a user is looking at DataSet values. sr Since the data set/data source is one layer lower than the report, its editor should not have dependency on report parameters. The previously suggested solution, described in comment #1, was to have the Data Set Editor provide the ability for users to overwrite/enter data source connection properties in the data set preview dialog, instead of using report parameters. Our understanding is that an user might have three different sets of Data source connection properties; one for design time, one for testing, and one for production. She would like to be able to preview both data set data and report output in any one of these three different environments, without changing the report design. Currently, each of the data source property may have a runtime property binding value, which gets applied at report runtime (including report preview). To support the above use case, a solution is to have an enhancement for an user to specify a different set of data source property bindings for each of the 3 environments. For example, the new set of design-time property bindings will get used, by default, at data set preview and editing a data set query. Note that a property "binding" value for design-time environment may be limited to assigning a literal value, and not a JavaScript expression. There may be a new design setting in UI where users can change when to use which set of property bindings. In addition, the Engine task API may also allow clients to specify which set of data source property bindings to apply. This enhancement requires more design considerations, and needs more user feedback on them. Marking this as a planned future enhancement. I have had some time to look at this more, this issue is tied up with this one: https://bugs.eclipse.org/bugs/show_bug.cgi?id=215497 The solution to the relative path issue is to use expressions in the parameter binding. This makes sense but the problem is that the parameter bindings are not used when working with the designer. So this solution will not work for the designer. Just to refine the scenario a bit more: - A Software company distributes BIRT using a single JDBC connection. - In production JDBC uses JNDI connection. - In Dev developers use Connection Profiles - Reports are extended to clients and services for modification or customization. - When report developers install software at client sites, there is no control over the location over where the workspace (or ConnectionProfile store) will be located. So absolute paths to the Connection Profile will not work. - When running reports, developer can use parameters to find the connection profile based on user developed expressions in the parameter binding. - When using the designer, the parameter binding is not run, so user can't use this behavior. - DESIRED CHANGE: When opening DataSource or DataSet editors, evaluate the expressions in the parameter binding to populate property values as needed. SIDE NOTE: One factor that has plagued me in development is the fact that the ReportContext that is instantiated and used when the DataSet editor is used is of a different class and is not populated. This means that the behavior of the scripts that access the ReportContext behave differently when executed in either the report engine or the data set designer. I realize that you don't want to have a dependency in the Data Set Editor on the ReportContext, and that makes sense from a pure design stand-point. At the same time, I would venture 99% of the DataSet editor users are Report developers. I wonder if if might make sense to create a special case of the DataSet editor that is used within the BIRT project that acts as a thin implementation over the standard DataSet editor which does not have the dependency. I have just gone to using a DriverBridge all the time. |