| RE: [birt-dev] BPS 66 - Chart Simple API SPEC.pdf |
|
After discussion with Wei, I agree we should put the extension point into new project “org.eclipse.birt.report.api.script”. Although the project should have been named as org.eclipse.birt.model.api.script, now we just do it by convention.
Thanks, Yulin From:
birt-dev-bounces@xxxxxxxxxxx [mailto:birt-dev-bounces@xxxxxxxxxxx] On Behalf Of Wei Yan
David,
When we include the org.eclipse.birt.report.engine.api.script packages into report engine, the package is only used by report engine in onPrepare to change the report design element through _javascript_ or java event handle. It is correct that the interfaces are owned by report engine at that time. It is the case 2 I described in my previous email.
With times going, the model needs a simple API to help the user change the report design easily. Those APIs can be used without report engine. It is the case 1 in my previous email. To avoid introduce two APIs in both MODEL and ENGINE, I think the MODEL choose to reuse the ENGINE API directly.
As the simple chart API is extended from the simple model API, so I think the user should be able to use the simple CHART API directly without report engine. That’s why I think the extension point should be defined in model.
For the the org.eclipse.birt.report.engine.api.script packages, I think it is part of the model api and should be moved to model plugin ( we needn’t change the the package name for the backward compatibility).
Thanks.
-Wei Yan
From:
David Michonneau
Wei,
The script engine API is in the report engine plugin, so I wonder why we need the extension point in the model plugin? The goal of this project is to provide a integrated and simple api for chart like the script engine API. The package name of that API isorg.eclipse.birt.report.engine.api.script
The extension point is needed to be able to instantiate the IChart when you call IReportDesign.getReportElement("chart name"); Since the implementation class of IReportDesign is done through ElementUtil.getElement(), which is also in the report engine, you need to instantiate the interface implementation from there (in the report engine), so it makes sense to have the extension in the engine, rather than the model. You can just add a case there for extended items, load the extension with the matching id, and create the class from the extension. I don't think the model will have any use for that extension, since it's a script engine api interface.
This API is not intended to be used in the Chart API standalone. The main reason is the integration with the scripting api (there is a dependency on the report script API, due to the extended interface) . That way, there will be a single API for accessing both report and chart elements, and report users won't need to learn a different API when using charts in a report. We do not want to add another API for standalone chart API users, which would be just confusing. We are looking in making the latter easier to use, but that's unrelated.
Thanks,
David
From:
Wei Yan
The APIs can be used in two different cases:
1. The user calls this API directly to change the report design, it may be used in the report designer, report template. In this case, the user doesn’t need the report engine, only the report model is enough. The user cases are:
The user has got the report handle somewhere. The user gets the IChart though the MODEL’s script API. The user changes the IChart through CHART API. The user saves the change the report design or uses it in somewhere else.
In this case, the CHART instance is created through MODEL API (such as getReportElement(“Chart”)).
2. The script API is used by BIRT, it is defined in the report design, and called by the report engine. In this use cases, there are several kinds of script need to be evaluated: 1. onPrepare User can define this script used to change the chart definition before execution. 2. onCreate User can define this script used to change the content created by the chart, the changing will be serialized into the report document. 3. onRender User can define this script used to change the content before the rendering. The changed content will be rendered immediately. 4. onPageBreak The script is called when there exits a page-break. The behavior is undefined now. In this case, the report engine should create the CHART Script instance (IChart) and evaluates the script. This spec only defines the CHART APIs used in onPrepare. The onCreate/onRender is not defined here.
It seems that:
1. The extension point should be defined in MODEL plugin instead of engine, as the user may call this API directly in case 1. 2. We don’t define a mechanism for extended container, such as XTAB. In this case, an XTAB is an extended item, the user may add other report items in the XTAB. After call the XTAB’s onPrepare, the report engine needs call the onPrepare defined in the inner child. To implement this, we needs exports getChildren() in the IReportItem, which returns the children IReportItem.
-Wei Yan
From:
birt-dev-bounces@xxxxxxxxxxx [mailto:birt-dev-bounces@xxxxxxxxxxx] On Behalf Of David Michonneau
Hi All,
Here is the specification document for the Chart Simple API project. Its goal is to provide a simple API to modify charts inside a report design through the BIRT Report Engine Scripting API. Note that there is a new extension point in the engine plugin for extended items to extend the engine’s IReportItem interface.
You can also find this document on the wiki at http://wiki.eclipse.org/index.php/BPS66
Thanks,
David |