Wei,
If you’re moving the
script API out of the report engine to the model plugin, I definitely agree it
should be a model extension point. That makes more sense to me indeed to have this
script api in the model. But then, our Chart simple API project (BPS66) is
dependent on that and is scheduled for M6. When can you complete the
migration of this API into the model, plus the new extension point? If needed
we can help you write that model extension point.
Thanks,
David
From: Wei Yan
Sent: Wednesday, March 07, 2007 11:07 PM
To: David Michonneau; 'For developers on the BIRT Charting project'
Cc: 'For developers on the BIRT project'
Subject: RE: [birt-dev] BPS 66 - Chart Simple API SPEC.pdf
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.
From: David Michonneau
Sent: Wednesday, March 07, 2007 10:16 AM
To: Wei Yan; 'For developers on the BIRT Charting project'
Cc: 'For developers on the BIRT project'
Subject: RE: [birt-dev] BPS 66 - Chart Simple API SPEC.pdf
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
Sent: Monday, March 05, 2007 11:38 PM
To: David Michonneau; For developers on the BIRT Charting project
Cc: For developers on the BIRT project
Subject: RE: [birt-dev] BPS 66 - Chart Simple API SPEC.pdf
The APIs can be used in two different cases:
- 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”)).
- 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:
- The extension point
should be defined in MODEL plugin instead of engine, as the user may call
this API directly in case 1.
- 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.
From:
birt-dev-bounces@xxxxxxxxxxx [mailto:birt-dev-bounces@xxxxxxxxxxx] On Behalf
Of David Michonneau
Sent: Thursday, February 22, 2007 3:40 PM
To: For developers on the BIRT Charting project
Cc: For developers on the BIRT project
Subject: [birt-dev] BPS 66 - Chart Simple API SPEC.pdf
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