The customizable report is an important concept in Style Intelligence. We have shown three ways to pass parameters to a report, either interactively or through static configuration files. In subsequent sections, we will demonstrate more ways to pass parameters and handle the requests. Since the replet architecture automates the entire parameter prompting and submission process, all a replet needs to do is declare the parameters it needs and build a report object accordingly. This provides the report developers with a powerful tool to create sophisticated custom reports.
As a generic API, the parameterization support can be used in any way a programmer chooses. However, there is a danger of overusing this feature and making the report too complicated to access. The following are some guidelines to help create more consistent and easy to use interactive reports.
• Initialization parameters should be used to configure static information. Normally, they should not be used to change the basic content of the report. Some obvious examples are parameters for a database connection, CORBA server locations and report template resource names.
• Creation parameters should consist of a relatively small number of options. If there are many configurable options on the report, most of them should be presented as Customized parameters. By keeping the creation parameters simple, users can quickly open a report without going through a large number of choices. If they choose to customize the report later, they can activate the customizer explicitly. This approach is less intrusive and more user friendly.
• Customization parameters should be used for dynamically changing report element attributes. This method provides a consistent and predictable way to customize a report.
View more examples in the InetSoft visualization gallery
The replet interactions are based on the distributed event-handling model. The BasicReplet API provides a few high-level methods for adding common interactions, such as hyper-links and popup menus. A programmer can also use the generic event handling API to add custom event handling to a replet.
All user interactions follow the same sequence:
1. A user action on the viewer generates an event.
2. The event is passed to the event handling routine. Simple events are handled in a client. If the client does not handle the event, the event is forwarded to the replet event handling routine over the network.
3. When an event is processed, one or more commands are returned from the event handling routine.
4. The command is executed on the client. If a command generates another event, the same process is repeated. Otherwise, the viewer returns to the waiting state.
Copyright © 2024, InetSoft Technology Corp.
