Community
Participate
Working Groups
The BIRT Extension Point APIs allow user to create their own ReportItems but this is a non trivial task. Data Binding, scripting, rendering are all non-trivial tasks that are required through the standard ReportItem extension points. There is little or no way at this time to create a new ReportItem that is based on the existing ReportItems. As an example, imagine that I have a custom type of DataItem with Named Expressions, and Event Handlers that respond to developer and data input. I would like to be able to bundle this item into a jar that is distributed with the Developer and Runtime products and discovered as a plug-in. Example items include: - Table - Labels - DataItems - TextItems - Grids
NOt sure how to use extension point to support the usage of extending DataItem to custom DataItem with Named Expressions, and Event Handlers that respond to developer and data input.
Are you saying you don't understand the objective, or you don't understand how it can be done?
(In reply to comment #2) > Are you saying you don't understand the objective, or you don't understand how > it can be done? > Don't understand neither.
If you want to create a new ReportItem, there is the ReportItem Extension which is a non-trivial task that does not leverage any of the built-in event handling or data handling. This is great if you need a whole new category of control e.g. charts or cross-tab. What I would like to be able to do is take some of the existing controls and extend them to do more. For instance, if you could add properties or methods to the report that are accessible from the scripting interface, and then you could populate the palette with this control it would allow users to extend the core report item to do more. As an example, I have figure out a way using Event Handlers to use a scalar parameter to add columns to a report at runtime. It is similar to the way a cross-tab works, but works better for some design situations. Unfortunately, to use this, the report designer has to manually build Named Expressions in the report. And they have to attach the EventHandler and mess around with the ScriptLib. I would like to have my ExtendableTable show up on the palette, with properties built in that the user could then implement. So it would involve extension of the Property Editor UI, as well as extension of the script interface.
(In reply to comment #4) > What I would like to be able to do is take some of the existing controls and > extend them to do more. For instance, if you could add properties or methods > to the report that are accessible from the scripting interface, and then you > could populate the palette with this control it would allow users to extend the > core report item to do more. > What is the reason/objective you would like to use Eclipse extension point to achieve this? Is there a common patten of extension so that a generic extension point can be defined on built-in report items?
I want to be able to create and share new BIRT objects that show up in the palette so that other developers can use them. I don't want to have to re-write the entire generation, presentation, and scripting interfaces like I do in the standard ReportItem extension. Think ReportItem extension as heavy-weight extension, from the ground up. Think of this extension as light-weight extension. For example I may want to use the ImageItem, but I want to embed special functionality around the image acquisition and presentation. I have some ability to do this through the event model, but re-use of the events is problematic for either JavaScript and or Java based event handlers. Also, it is hard to make this a seamless integration. I think that some of the common patterns of extension would be to: a) improve the Property Editor Interface through new or customized pages b) modify the behavior at instantiation c) modify the behavior at generation time d) modify the behavior at presentation time e) extend the core scripting function The idea is: More power then Event Handlers while Less work than ReportItem Extension
This is similar to 223130 but different. 223130 is focused on adding components but not changing the model. This is focused on adding to the model.
Any suggestion on a common extenion point among all the report items? I can see each report item extension can define its own extension point to allow others further extend the report item. An alternaitve solution to discuss is to copy the plugins of the existing report items, rename the report item to such as "myDataItem", then modify it to meet the customization needs? Is it an issue or benefit to NOT share code or inherit implementation from the original built-in report item? Any other solution?
Still would love to see this: - In terms of what needs to be extendable, I would say all of the main palette elements. - Why not just copy and paste. The problem is that taking an existing element and trying to re-create a new one from it is a huge task, and not really supported. The ReportItem extension objects function differently from the core objects.
