NextReports Server allows to link an infinite number of drill-down widgets.
Version 5.2 of NextReports Server has a new "Up to Root" link which will make it easier to return to the first entity from wherever the user is inside the drill flow:
Tuesday, May 29, 2012
Tuesday, May 15, 2012
Wicket : Change an AjaxSelfUpdatingTimerBehavior
NextReports Server supports an automatic refresh for widgets. Just clicking "Edit Settings" for one widget will bring the following dialog:
Here user can modify "Refresh Time" which tells how many seconds should pass till next auto refresh.
To make this happen , an AjaxSelfUpdatingTimerBehavior is used. By default there is no refresh time set (value is 0). A change will imply to stop previous AjaxSelfUpdatingTimerBehavior and to create a new one if that's the case:
Here user can modify "Refresh Time" which tells how many seconds should pass till next auto refresh.
To make this happen , an AjaxSelfUpdatingTimerBehavior is used. By default there is no refresh time set (value is 0). A change will imply to stop previous AjaxSelfUpdatingTimerBehavior and to create a new one if that's the case:
for (Behavior behavior : widgetPanel.getBehaviors()) {
if (behavior instanceof AjaxSelfUpdatingTimerBehavior) {
((AjaxSelfUpdatingTimerBehavior) behavior).stop();
}
}
if (refreshTime > 0) {
widgetPanel.add(new AjaxSelfUpdatingTimerBehavior(Duration.seconds(refreshTime)));
}
There are two things to have in mind:- AjaxSelfUpdatingTimerBehavior must not be removed because, after stop, the event is called one more time on the client, so it has to be present.
- When we already have a refresh time set (greater than 0) and we want to modify its value, if a refresh is done when the dialog is opened, the desired panel no longer exists. So the user will be informed about this through a message (otherwise an error would have been raised):
Wednesday, May 09, 2012
NextReports : Templates for Parameters' Values
When we define parameters in NextReports Designer we can select default values for parameters. These values will be automatically selected in user interface when user runs the report.
There are some special cases of reports with a lot of parameters, when the user may want to have more than a group of default values. To allow such functionality, version 5.2 of NextReports Server will bring a new feature : Templates for Parameters' Values.
Basically, inside the runtime parameters panel, user will be able to save a template of values or to select a previously saved template to automatically load all values.
To save a template, user has to check "Save as" option and to enter a name for the template. Advancing to next step or just finishing will save the values template inside repository. On other runs for same report, user will be able to select the template.
Templates can also be removed by selecting them from a list.
So, in case you have reports with many (dependent) parameters and you need the way to run more variants without a lot of selecting , start using values templates.
There are some special cases of reports with a lot of parameters, when the user may want to have more than a group of default values. To allow such functionality, version 5.2 of NextReports Server will bring a new feature : Templates for Parameters' Values.
Basically, inside the runtime parameters panel, user will be able to save a template of values or to select a previously saved template to automatically load all values.
To save a template, user has to check "Save as" option and to enter a name for the template. Advancing to next step or just finishing will save the values template inside repository. On other runs for same report, user will be able to select the template.
Templates can also be removed by selecting them from a list.
So, in case you have reports with many (dependent) parameters and you need the way to run more variants without a lot of selecting , start using values templates.
Monday, April 30, 2012
Wicket 1.5 and general models
NextReports Server is in process for Wicket 1.5 migration. A lot of things need to be addressed, but in particularly one of them has to be noticed.
Running reports in NextReports Server consists of a number of steps, one of them being selecting parameters. Depending of parameter's type, user can choose the values using a specific UI component like text field, check box, combo box, calendar, selection lists and so on.
Model used for a parameter is something generic like Serializable, because it's type can be anything. One problem appeared at migration from version 1.4 to version 1.5. A simple String TextField with a Serializable model (objectModel in our case):
Running reports in NextReports Server consists of a number of steps, one of them being selecting parameters. Depending of parameter's type, user can choose the values using a specific UI component like text field, check box, combo box, calendar, selection lists and so on.
Model used for a parameter is something generic like Serializable, because it's type can be anything. One problem appeared at migration from version 1.4 to version 1.5. A simple String TextField with a Serializable model (objectModel in our case):
TextField<String> textField = new TextField<String>("txtValue",
new PropertyModel<String>(this, "objectModel"));
When we put a value in our text field, on submit we get : "is not a valid Serializable" error. That shows us Wicket 1.5 does not know that String declaration in our case is a Serializable type. To make models accept a general type , we should now create also the converter used by the component to specify the class type:TextField<String> textField = new TextField<String>("txtValue",
new PropertyModel<String>(this, "objectModel")) {
@Override
public <C> IConverter<C> getConverter(Class<C> type) {
return new AbstractConverter() {
public Object convertToObject(String value, Locale locale) {
return value;
}
@Override
protected Class getTargetType() {
return String.class;
}
};
}
Wednesday, April 18, 2012
NextReports : Row Formatting Conditions
Till version 5.2 NextReports allowed only cell formatting conditions. But the new version will also bring the possibility to add row formatting conditions.
User can select now a row
and row properties will be seen:
Clicking on formatting conditions, user can add, edit or remove them:
In this example we just alternate background color for rows:
We can go further and alternate not rows, but records data. Consider the following report:
We will modify row formatting conditions for all rows like following:
We will obtain:
We can modify more properties for a row formatting condition. For next report:
we will select background and border properties:
Result is:
We can have any expression used for row formatting. Next shows a row formatting simulation if productivity is less than 50%:
If you want to combine cell and row formatting conditions, keep in mind that cell formatting conditions will overwrite row formatting conditions.
User can select now a row
and row properties will be seen:
Clicking on formatting conditions, user can add, edit or remove them:
In this example we just alternate background color for rows:
We can go further and alternate not rows, but records data. Consider the following report:
We will modify row formatting conditions for all rows like following:
We will obtain:
We can modify more properties for a row formatting condition. For next report:
we will select background and border properties:
Result is:
We can have any expression used for row formatting. Next shows a row formatting simulation if productivity is less than 50%:
If you want to combine cell and row formatting conditions, keep in mind that cell formatting conditions will overwrite row formatting conditions.
Subscribe to:
Posts (Atom)
















