Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 142609

Summary: Report Parameters enhancement
Product: z_Archived Reporter: Huynh <khuynh45>
Component: BIRTAssignee: Yuejie Chen <yuejie.chen>
Status: RESOLVED FIXED QA Contact:
Severity: enhancement    
Priority: P3 CC: certqb
Version: unspecifiedKeywords: plan
Target Milestone: 2.2.0 M4   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Attachments:
Description Flags
attachment 1
none
attachment 2 none

Description Huynh CLA 2006-05-18 15:49:09 EDT 
We need a way to replace or extend the Report Parameters for both design-time (report designer) and run-time (report viewer) environments.

We have a complex requirement for prompting for user input when executing a report.  Please see attachments for screen shots of an example of our current win32 solution.  Basically, the first prompt input will drive what to populate for the next prompt (it's similar to Cascading Parameter Group), however it's a bit more complex in how we tie the data retrieval logic to the prompt.  One example is the Lookup Last Name and Person Search prompts.  These prompts are tied to an adhoc query, so you can filter the data dynamically.  In addition, the report designer (person) has complete control over the placement of the prompts.  JavaScript is also used to provide additional capabilities for controlling the prompts' behavior.

I may have missed something, but I'm not aware of any extension point currently allows this level of customization.  It would be great if BIRT framework can be extended for domain specific prompting implementation.
Comment 1 Huynh CLA 2006-05-18 15:50:12 EDT 
Created attachment 41927 [details]
attachment 1 [details]
Comment 2 Huynh CLA 2006-05-18 15:50:35 EDT 
Created attachment 41928 [details]
attachment 2 [details]
Comment 3 Wenfeng Li CLA 2006-05-21 18:49:21 EDT 
Since parameter promoting is a web application, we will not be able to provide OSGi extension points for this customization, but you can have a custom web application to fully customize the parameter collection before calling report engine to run the report.  BIRT report viewer code can be used as an examples how this can be done.
Comment 4 Huynh CLA 2006-05-22 11:20:36 EDT 
This would only solve run-time parameter prompting (Would the Rich Server Platform project solve the OSGi problem in the future?). We've planned to have custom viewers for both RCP and Web environments to handle our legacy and BIRT reports. To facilitate this, we would need to have our own (design-time) parameter/prompt builder. Since the BIRT report parameter builder is tightly integrated with the report designer, can this be refactored into an OSGi extension? This would allow us to provide our custom builder that hooks into the BIRT framework.
Comment 5 Wang Qiangsheng CLA 2006-09-27 04:22:37 EDT 
Consider if it's possible to provider extension point to let user customize the parameter design dialog.
Comment 6 Yuejie Chen CLA 2006-11-24 01:38:22 EST 
(In reply to comment #4)
> This would only solve run-time parameter prompting (Would the Rich Server
> Platform project solve the OSGi problem in the future?). We've planned to have
> custom viewers for both RCP and Web environments to handle our legacy and BIRT
> reports. To facilitate this, we would need to have our own (design-time)
> parameter/prompt builder. Since the BIRT report parameter builder is tightly
> integrated with the report designer, can this be refactored into an OSGi
> extension? This would allow us to provide our custom builder that hooks into
> the BIRT framework.
> 
Huynh,
we have refactored our views code in 2.2, and add a ElementAdapter extension to make our views more extensible and customizable. You can check out the latest code(include plug-in org.eclipse.birt.report.designer.ui.views, which we added recently), and look through the org.eclipse.birt.report.designer.ui.elementAdapters extension point in plug-in org.eclipse.birt.report.designer.ui. Now, the views content are contributed by elementAdapters extension point. To provide a view content(labels, context menus..), you can implement a INodeProvider, then register it as ElementAdapter with view content model. For details, you can refer to the implementation in plug-in org.eclipse.birt.report.designer.ui.views.

BTW, the code and the extension schema are not stable, may change in future until 2.2 release.
Comment 7 Huynh CLA 2006-11-27 08:54:13 EST 
> Huynh,
> we have refactored our views code in 2.2, and add a ElementAdapter extension to
> make our views more extensible and customizable. You can check out the latest
> code(include plug-in org.eclipse.birt.report.designer.ui.views, which we added
> recently), and look through the
> org.eclipse.birt.report.designer.ui.elementAdapters extension point in plug-in
> org.eclipse.birt.report.designer.ui. Now, the views content are contributed by
> elementAdapters extension point. To provide a view content(labels, context
> menus..), you can implement a INodeProvider, then register it as ElementAdapter
> with view content model. For details, you can refer to the implementation in
> plug-in org.eclipse.birt.report.designer.ui.views.
> 
> BTW, the code and the extension schema are not stable, may change in future
> until 2.2 release.
> 

This is great. I'll give it a try.

Thanks
Comment 8 Yuejie Chen CLA 2006-12-05 00:45:09 EST 
Huynh,
i will mark this bug as fixed for 2.2.0M4 release build, if you found that the new extension not suits you, you can reopen it, we can do more investigation.