Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Note: This document needs to be updated to fully match the function system of 0.8.9/0.8.11.

Functions

JFreeReport supports two kinds of userdefined calculations: Functions are statefull calculations, when the report proceedes they change their state, they sum up, calculate averages, count etc. Statefull means in that case, given you feed the same event multiple times into the function, it is not guaranteed that you get the same result.

Expressions in contrast do not maintain a state, they calculate a value or change the report-elements depending on the current Event feed to them. If you feed the same Event into the Expression multiple times, you will always get the same result.

If possible try to prefer Expressions over functions, as expressions are easier to write and comsume less resources.

Using Functions and Expressions

The following section apply to both functions and expressions, I will refer to both types using the term ?function?.

Functions and expression will be configured using a set of properties ? these properties are private to the function instance and will not be shared with other functions. Which properties need to be defined is dependend of the used implementation.

Expressions and functions must have assigned a name, the name must be unique within the datarow to access the functions computation result.

Functions are added to the report before the report processing starts. If you use the API, you will use the JfreeReport.addFunction() or JfreeReport.addExpression() methods to add the function objects to the report.

When using the xml, you will specifiy the functions in the ?functions? tag of the report definition file. The functions declaration is equal for both report definition formats.

Function dependencies

Functions may query other functions and user these foreign results for their own computations.

The order in which functions get informed of events is undefined for functions of the same dependency level, but it is guaranteed, that all functions are executed in the order of their
dependecy level. Functions with an higher dependency are executed before any function with an lower dependency. The execution order of functions with the same dependecy level is undefined.

Lets have a look at a small example:

Assume we have defined three functions named A, B and C. Furthermore we define, that function A, B and C are numerical functions and that C computes the sum of A and B.

When all functions have the same dependency level, the order of the event calls is undefined, so that the function A or B may contain invalid values when queried from C. So resolve this relationship, we have to declare that function C depends on A and B. This can be done by setting the dependency level of A and B higher than the dependency level of C.

When C has a dependency level of '0', we will have to define our functions A and B to have the dependency level of '1' or higher to make sure that the computation is valid.

When using the API, the dependency level is read by "getDependencyLevel()" and can be set with "setDependencyLevel(int)". In the XML definitions, the dependency can be defined using the attribute ?deplevel?.

By default all user functions have the dependency of "0", the lowest possible level. System functions like the page layouter have the dependecy level -1 or lower to make sure that all expressions are evaluated. You cannot set the dependency of normal functions or expressions lower than '0'.

Dependencies between Expressions are not resolved automaticly. The order of the expressions on the report determines the evaluation order in the report. A expression that references an other expression's value that is computed after the current expression will behave non-deterministic, as it will receive an old and invalid value from the datarow.

The life cycle of functions

Functions are objects and are constructed like any other object using an constructor. The function implementation is loaded via its default constructor by the report parser, all function implementations which should be used from within the xml-definitions must define a public default constructor. The functions implementation is defined by specifiying the "class" attribute of the "function" tag and is loaded by using the default class loader. Your function implementation must be in the classloaders classpath.

After constructing the function or expression, the properties of the function will be set. The xml parsers use calls to the setProperty() method of the function or expression to set the function. The parser will not use any possibly defined accessor method (getter/setter) to set the properties.

Before functions can be used, they need to be initialized. The main purpose of this method is to verify that the function is defined properly and that all required properties are set. During the initialisation of the report function, you won't have access to the report object or the report properties or report configuration. The initialize() method is the place to check whether the functions parameters are correctly set, not to do any work.

Note: The BeanShell expression uses this method to compile the beanshell script, the script has to take care that the dataRow reference is null at this moment.

If you want to initialize certain values depending on the report configuration or the report definition, you will have to relocate your code from the method initialize() into the method reportInitialized(ReportEvent event), At this point you have full access to the report definition and all helper objects.

The method getProperty does not access the report properties, it accesses the functions properties. These properties store the function parameters and are set within the function declaration:

There is a fundamental difference between ReportProperties and function properties: Report properties are bound to the report object, which is accessible via report.getProperties().getProperty(). Be aware that within a function you don't have access to the original JFreeReport object, all report related operations are performed by using the ReportDefinition object from the current report event.

During the event handler methods, you can access the datarow of the current report event to query the current row of the tablemodel, other expressions and functions or the report properties.

Data is fed into the function/expression by using a DataRow object. This object provides the (among others) these methods

  • Object get(String name);
  • Object get(int columnName); // DEPRECATED.

to read the values of a function, expression, a column from the tablemodel or a ReportProperty (which must be marked as datasource before).

As with every function, a single function can return one value, something mathematicans express like y = f(error), where x is the data from your report processing.

The functions or expressions computed value is returned by the "getValue()" function. You can return any Object, but make sure, that this object does not get modified anymore after it was returned to the caller. (A simple way to obey to this rule is to create a new object whenever the computed object changes).

Function specific lifecycle

Functions live in an own environment, separated from the outside world. Changing the original JFreeReport object does not affect the inner JFreeReport-Object. You are also unable to add new Functions or expressions to the report from inside, so all functions and expression have to be set and initialized before the report processing has begun.

All Functions have to be cloneable. It is not guaranteed that the report is processed in an linear order, but it is guaranteed that a single instance of a function does pass a reportstate only once.

That means: When processing the report, the system clones the functions on certain save-points (for instance whenever a page is finished). This saved copy can later be used to restart the report processing on that saved point. The copy-state made will never return to a previous save point, but it can (and certainly will occur) that this copy is used to process the report from that saved point on.

So when saving a state after page 2, it will never happen, that this page-2-copy gets used to process page 2 a second time, but it could happen that copies of this page-2-state process the page 3 again and again.

The best way to avoid cloning problems is to use Unmodifiable objects or primitive datatypes when storing a state. Using java.lang.String, one of the java.lang.Number implementers or any other unmodifiable object type is always save. If you use complex objects, lists or hashtables and you get weird results, try to implement a deep-object-copy in the clone() method of the function for these objects.

Event order for functions

A function receives the following events in the given order:

  • ReportInitialized event
  • (pageStarted event)
  • prepareEvent (ReportStarted)
  • ReportStarted event
  • prepareEvent (GroupStarted)
  • GroupStarted event
  • prepareEvent (ItemsStarted)
  • ItemsStarted event
  • prepareEvent (ItemsAdvanced)
  • ItemsAdvanced event
  • prepareEvent (ItemsFinished)
  • ItemsFinished event
  • prepareEvent (GroupFinished)
  • GroupFinished event
  • prepareEvent (ReportFinished)
  • ReportFinished event
  • prepareEvent (ReportDone)
  • ReportDone event
  • (PageFinished event)

The prepare events are used to inform the listeners, that the next state is going to be processed. When this event is thrown, no change was done by the state yet. The main purpose of these events is to help the function to clean up its internal states before the new state is beeing processed. The PageLayouter functions starts a new page and print eventually contained spooled bands after a pagebreak was done, when this event is received.

The page events are inserted whenever needed. They are a little bit tricky to handle right now, but this will change with the next release ? then this part of the documentation handling the page events will be completed.

If you want to see, which and when events are fired during the report processing, you may want to include the EventMonitorFunction into your report. This function does not return any values, but prints a lot of log messages whenever an event is sent to that function.

Implementing the classes

Expressions are simple and easily explained: Expression have the method

Object getValue() which is called when the expression is queried. All expression have to override this method to perform the calculation and to return the value.

Functions are more complex:
Functions have several notification methods, where the system informs the function that a new event is processed.

  • public void pageStarted (ReportEvent event);
  • public void reportStarted (ReportEvent event);
  • public void groupStarted (ReportEvent event);
  • public void itemsStarted (ReportEvent event);
  • public void itemsAdvanced (ReportEvent event);
  • public void itemsFinished (ReportEvent event);
  • public void groupFinished (ReportEvent event);
  • public void reportFinished (ReportEvent event);
  • public void pageFinished (ReportEvent event);

By using the Event-object, you have access to the ReportState. The state can be used for getting the current group, current item and for gaining access to the dataRow. In case you want to manipulate the ReportElements, you also have access to the JFreeReport object.

Using the functions

The function implementation is loaded via its default constructor by the report parser, all function implementations which should be used from within the xml-definitions must define a public default constructor. The functions implementation is defined by specifiying the "class" attribute of the "function" tag and is loaded by using the default class loader. Your function implementation must be in the classloaders classpath.

As with every function, a single function can return one value, something mathematicans express like y = f(error) where x is the data from your report processing.

A function is called several times, for every state change (whenever the report advances) one of the ReportListener methods are called (reportStarted, groupStarted etc). Expressions do not receive events, they just perform their computations based on the current state.

The functions value is returned by the "getValue()" function. You can return any Object, but make sure, that this object does not get modified anymore after it was returned to the caller. (A simple way to obey to this rule is to create a new object whenever the computed object changes).

Functions may reuse results from other functions by using and querying the DataRow object supplied in the report state or the function.

The order of the functions and the order for receiving events is undefined for functions of the same dependency level. So if you define a function which reads values from an other function, it is wise to define the dependencies for these functions.

Defining dependencies is easy: A function with an higher dependency is called before any function with a lower dependency. By default all user functions have the dependency of "0", the lowest possible level. The dependency is defined by specifying the "deplevel" attribute of the function or expression tag.

When using the API, the dependency level is read by "getDependencyLevel()" and can be set with "setDependencyLevel(int)".

For the example above, the caller function would have the dependency level of '0' and the called function the level of '1' or higher.

  • No labels