Post your feature requests hereBack to Forum List >> Back to Topic List
Required report layout zoom feature
Posted 6 Days Ago By Mihai
Because report layout can contain components with very small fonts, a zoom feature is needed for a good visibility.

This feature is available from version 3.4.
|
Stored Procedure Support
Posted Friday, 27 March 2009 By Josh Martin
Modified: Friday, 27 March 2009
In addition to tables and views, it's critical to support stored procedures to retrieve data. This allows more complex reports to be hidden by stored procedures.

Please note that some databases (MySql) allow SELECT FROM PROCEDURE syntax, while others (Oracle) rely on cursors (ref cursors). It's critical that both are supported - i.e. I should be able to point to an Oracle procedure, pass in parameters, and get the ref cursor results back as a table. Here's a short example of how results are returned from an Oracle stored procedure:

PROCEDURE sample (
p_1 IN VARCHAR2,
p_2 IN VARCHAR2,
refcur OUT sys_refcursor
)
IS
BEGIN

OPEN cur_worker FOR
SELECT * FROM Whatever
WHERE Col1 = p_1
AND Col2 = p_2;

END sample;

(This could also be inside an Oracle package).

Thanks,
Josh
|
Stored Procedure Support
Posted Monday, 30 March 2009 By Mihai
Modified: Tuesday, 31 March 2009
We will evaluate this and see what it implies under the hood.
|
Re: Stored Procedure Support
Posted Tuesday, 31 March 2009 By Josh Martin
Mihai -

That would be great. Our current product uses JReport, and we are considering moving to BIRT. However, we really only need table-based reporting, and NextReports looks perfect. Several of our "queries" have some business logic (if/else/etc.) in them, and procedures are the way we implement this.

The other way we could do this was to allow a Java class to be the "data generator". I.e. rather than a report using a SQL query to get its data, if we could provide a Java class (that implemented a NextReports interface), we could let that class connect to the database, return the results, perform the logic, etc. E.g.

package nextreports;

public interface DataProvider {

/** Provides the connection to the provider */
public setConnection(Connection c);

/** Passes the report so the parameters can be used */
public List getResults(Report r);

}

Just a first thought as an example...
Josh
|
Stored Procedure Support
Posted Friday, 03 April 2009 By Mihai
We will add stored procedure support in version 2.2.

In the query editor you will be allowed to write :

for Oracle :
call my_schema.my_procedure(${P1}, ... , ${Pn}, ?)

for MySql:
call my_schema.my_procedure(${P1}, ... , ${Pn})

where P1, ... , Pn are parameters defined in the query. Every such parameter will have also a previewValue which must be used inside the procedure to exit as fast as possible. That is necessary because when a new report is created from a query , we must look for the report columns and we do not want the procedure to make some business for such cases.

Only the out parameter is mandatory for Oracle. The IN parameters number may be zero.

For MySql there is no out parameter.
|
Accessibility in Reports
Posted Friday, 27 March 2009 By Josh Martin
NextReports -

I'm a Java developer and am very excited to potentially use your product embedded in a reporting application we use. One of our key requirements is accessibility (a.k.a. 508 compliance).

Since your reports are table-based (exactly what we're looking for), it should be easy to implement. There is a similar request (with the requirements) in the BIRT reporting tool:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=178171

Essentially, the output table headers in HTML () should support the "scope" and "id" attributes. The output table rows () should support the "headers" attribute. This is fully outlined here:

http://www.w3.org/TR/REC-html40/struct/tables.html#h-11.4 />
Putting these values in the "Properties" section of your IDE would make it really easy to use. You would just need to take these values and putting them in the HTML output.

If this is a possibility in the short-term, it would definitely sway my decision away from using BIRT (since we really just need table-based outputs).

Thank you,
Josh
|
Accessibility in Reports
Posted Monday, 30 March 2009 By Mihai
We can add in Properties panel three new accessibility properties for scope, id , headers for every cell and these will be taken into account just for html export.
For html export we use only tr and td tags. For scope we can use a combobox editor with row and col as values. For id and headers properties we will use a simple textfield editor (and user can enter anything he wants).
For a cell with ${column} from database, this cell will be generated for every entry, and all will have the same value for that property (scope, id, headers). Is that ok?
If that's ok we can implement this in a few days.
|
Re: Suggested Implementation for Accessibility in Reports
Posted Tuesday, 31 March 2009 By Josh Martin
|
Re: Suggested Implementation for Accessibility in Reports
Posted Wednesday, 01 April 2009 By Mihai
From the W3 definition I understand that rowgroup has a meaning only if rows in html are grouped into a table head, table foot, and one or more table body sections using the tags THEAD, TFOOT, and TBODY. But these tags are not used in NextReports html generation (only TR and TD are used). And the same for colgroup, it has a meaning only if the tags COLGROUP or COL are used. So, isn't it meaningless to add rowgroup and colgroup to the dropdown scope attribute?
|
Re: Suggested Implementation for Accessibility in Reports
Posted Wednesday, 01 April 2009 By Josh Martin
Yes that makes sense. If the output is only TR and TD tags, then adding those options would just add confusion. I.e. row and col would be fine.
|