Community
Participate
Working Groups
Created attachment 92044 [details] Bidi Design Specification Build ID: M20070921-1145 Currently, BIRT users face a number of problems related to developing and rendering of Hebrew and Arabic reports, such as: - Inability to define and customize Bidi aspects of report behavior - document-wide orientation and item-level text direction - at design time; - Lack of overall Bidi design environment, including a WYSIWYG graphical editor; - Lack of data normalization necessary to synchronize data originated from different data sources; - Lack of Bidi capabilities in report engine; - Lack of Bidi enablement in embedded report viewers. We would like to contribute code to this project, improving Bidi capabilities of the BIRT design tool and report engine.
Created attachment 92045 [details] Patch against BIRT_2_2_1_Release_20070924 Note: the attached code does not use any third party code or library.
Created attachment 92047 [details] Complete new Bidi plug-ins Note: this attachment does not use any third party code or library.
Created attachment 92088 [details] Patch A small addition (not included with the previous attachments). Again, it does not use any third party code/libraries.
Is this patch only for Win32 platform? I see Win32 specific code in BidiUIUtils. Or other platform doesn't need the patch?
(In reply to comment #4) This patch is for Win32 platform only. For the time being, other platforms were not patched, since they are not well supported for right-to-left natively.
This meta bug will track all Bidi-related issues in BIRT.
Comment on attachment 92045 [details] Patch against BIRT_2_2_1_Release_20070924 The code changes will be delivered through other bugzilla entries.
In reply to Section 3.4 of the document on transformating backend data from an input BIDI Format of an External System (ODA Data Set). We see that the BIDI format support is one of data formatting and presentation. From the BIRT system architecture perspective, the BIRT Data Engine is mainly responsible for handling data values, rather than with its presentation. So any conversion from/to BIDI format should be handled outside of the Data Engine. In other words, when the Data Engine fetches data rows from an underlying ODA data set, the data retrieved are expected to have been converted to a logical format already. Thus it is the responsibility of an underlying ODA data source provider to convert from the input BIDI format. Similarly, when an ODA designer defines an ODA data set design for consumption by a BIRT report design, any of its design metadata collected from its custom UI that are in visual format should also have been converted. Examples of such design metadata are a data set's query text, result column and parameter's display name, default value, etc. So from the above perspective, the input BIDI format info collected on a BIRT Data Set Wizard/Editor (proposed in section 3.4.1) is not applicable. With the input BIDI format conversion being the responsibility of an ODA data source provider, it would be useful to provide a BIDI input conversion utility extension that can be used any custom ODA data source provider. In other words, move the input BIDI conversion handling, currently proposed to be in the BIRT Data Engine, out to an BIDI Convertor ODA driver bridge extension. This would be an ODA driver bridge that implements the org.eclipse.datatools.connectivity.oda.consumer.driverBridge extension point. For more info on the ODA driverBridge extension point, see the ODA Wiki page http://wiki.eclipse.org/Use_Case_-_Extending_an_ODA_Runtime_Driver .
Linda: Thank you very much for the review and the pointers. We will carefully review our design.
Wenbin, would it be possible to incorporate the new Bidi plugins (attachment 92047 [details])? We will supply codes that use these plugins later (mostly for Data transformation and in the UI). For now, there would be no actual impact on the 2.3 code).
(In reply to comment #10) Lina, How will the plugins in attachment 92047 [details] get used later (mostly for Data transformation and in the UI)? As pointed out in comment #8, the original related design should be revamped, and implementation moved to different components. Some of the proposed implementation, such as extending the DataSetEditor, may no longer be needed. I'd recommend to first have a better picture of the overall design, before introducing unused code into the build.
Well, I didn't mean to ask for introducing code already known as subject to change. It's true that BidiDataSetEditor constitutes an example of such code (and sorry for overlooking it). However, I don't think this applies to the rest of the attachment. This attachment includes 3 plugins: (1) org.eclipse.birt.report.bidi: Bidi transformation engine (apparently independent of the implementation of its clients), fixes for the SQL editor and right-to-left enhancements for the Eclipse-based Designer (not related to the Bidi transformations). (2) org.eclipse.birt.report.designer.ui.bidi: BidiDataSetEditor. (3) org.eclipse.birt.tests.bidi: a set of JUnit test cases. If there is a basic agreement that some parts can be released at this point, I will prioritize those included with plugin (1) and indicate which of them would become useful pretty soon.
(In reply to comment #12) A good part of plugin (1) (org.eclipse.birt.report.bidi) are very specific to handling a SQL statement text, and should not be used directly by any BIRT core components. Those implementation are thus not a generic BIRT report utility, and should not be packaged in the plugin. So in effect plugin (1) is subject to change as well. It will be quite useful to apply the SQL-specific BIDI implementation on top of the BIRT oda.jdbc and other SQL-based ODA data sources. So those codes should be re-factored and packaged into an ODA driver bridge extension in BIRT, which can be used by any custom ODA data provider. For the small remaining, general purpose BIDI transform implementation in the plugin, it would still be good to identify its clients. It will help us in the review to have a better picture of the overall design that incorporates the various design comments. BTW, most of the code could use more Javadoc comments ;-)
Linda, thanks indeed for your valuable comments. Our intention was to isolate Bidi implementation from the base code as much as possible, but we can relocate it if that's your preference. I think that changes concerned with SQL statement text address both "content" (e.g. SQL query text formatting prior to the query execution) and "presentation" (Eclipse editors, incuding the SQL editor per se (JDBC SQL DatasetEditor page) and the "mini-SQL Editor" (query property CellEditor). Implementation for SQL-related content formatting can be definitely placed in oda.jdbc. Changes for SQL editors though are consumed by different plugins, so we located them outside of oda.jdbc.ui. However, this can be re-factored anyway as well. On the contrary, most of the Bidi transform API deal with generic text content and are not aware of the semantic meaning of that content. Also, in future we may decide to introduce Bidi format properties at the report output level (in addition to the input level as at present) and not necessarily in the context of Data source. So I still believe that Bidi transform could be treated if not generic then at least a multi-purpose report utility. Finally, IMO all the changes supplied within the (current) Bidi plugins should not be considered API-related.
(In reply to comment #8) The developer who implemented this part (and is currently on vacation) will address your comments in detail. For the moment, let me ask some rather common questions. > ... when the Data Engine fetches data rows from an underlying ODA data set, > the data retrieved are expected to have been converted to a logical format > already. Thus it is the responsibility of an underlying ODA data source > provider to convert from the input BIDI format. > Similarly, when an ODA designer defines an ODA data set design for consumption > by a BIRT report design, any of its design metadata collected from its custom > UI that are in visual format should also have been converted. Examples of > such design metadata are a data set's query text, result column and > parameter's display name, default value, etc. > So from the above perspective, the input BIDI format info collected on a BIRT > Data Set Wizard/Editor (proposed in section 3.4.1) is not applicable. I think this information is collected *before* the Data Engine fetches data rows from an underlying ODA data set. User can invoke the managed dialog proposed in section 3.4.1 from the very first screen of the New Data Set wizard. If that's not a right place anyway, what could be alternatives? How can a (human) user communicate the format settings to the data source provider? (Such information cannot be retrieved from the external data source itself.) Linda, did you just mean that the phrase "User will be allowed to change DataSet's Content Bidi format through the Property view after creation of Data Set." is not applicable? If so, it's possible not to give user the ability to modify these characteristics later on.
Currently we associate Bidi format with a Data set instance, not a Data source. The reason is that one Data source may contain data units in different Bidi formats. Given that, should Bidi transformations be the responsibility of a new data source provider?
(In reply to comment #14, #15, #16) For the Bidi transform utilities that deal with generic text content, which component(s) in BIRT will be its client? If some of them are for use during report runtime, those utilities should then be packaged in a runtime plugin that can be installed as part of the BIRT Report Engine runtime package. If some of them have UI dependencies, they should be packaged into a separate plugin for inclusion in the BIRT report designer packages. RE: the UI page that collects input BIDI format info, and which component it belongs to… the main deciding factor is which component(s) will consume such info. In section 3.4.1, it seems the UI page is proposed to be a BIRT host designer page, which implies the info is for direct consumption by BIRT Data Engine. From what we have discussed, the underlying ODA data provider would take care of the BIDI input format conversion, based on the BIDI input format info. Thus the UI page that collects the BIDI format info should really be a custom data set UI page contributed by an ODA data provider, similar to the "Query" custom page contributed by oda.jdbc.ui. Similarly, the proposed ROM schema changes to the OdaDataSet element would have the same criteria. An explicitly defined element in the ROM Data model is normally consumed directly by BIRT core component(s). If those BIDI elements are intended for persisting the BIDI input format info collected by the custom UI page, they should be stored in the public or private properties element(s) of an OdaDataSet. Note that refactoring of the data source/set specific BIDI implementation to an ODA data provider does not mean that they have to be packaged directly into an ODA data source component, e.g. oda.jdbc and oda.jdbc.ui. Instead they can be packaged into separate plugins (ODA runtime driver bridge and designer components) which are then "used" by individual ODA data sources. For example, the oda.jdbc plugin manifest can add an ODA driverBridge extension to declare the BIDI ODA runtime driver (packaged in a separate plugin) to be its runtime bridge. (This is obviously assuming the BIDI ODA runtime driver is implemented to act as a bridge.) In additon, the oda.jdbc.ui extension can define a second custom data set UI page that uses the BIDI ODA UI page class (packaged in a separate BIDI ODA designer plugin). This way, other ODA data providers can also choose to use the BIDI ODA components as needed.
Linda, thanks again for the very helpful comments. I think at this point I will remove/obsolete patches concerned with Bidi format and rework our proposal in that area. As a new proposal meets the requirements, we will work on its implementation and provide a new patch for Data exclusively.
Comment on attachment 92047 [details] Complete new Bidi plug-ins Per comment #18, these plugins are obsolete, pending refactoring.
Mark this as fixed as we have completed all features as designed.
