Hi,
i think for me a good evolution in ussrp would be the possibilty to add parameters to the reports, defining default values, and isForPrompting capabilities like in iReport.
I'll try to add these capabilities on my own.
I wanted to share this point of view with ussrp developers.
Eric
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
it would be great to see what you come up with. it is top on my list for me as well - maybe we can collaborate. here are a couple ideas:
1 - params are defined at report design time
2 - ussrp needs to provide a controller that can parse report parameters in a query string
3 - if ussrp had a ReportParameter object, it would need two Strings: 1 - type (e.g. "java.lang.Integer") and 2 - value (e.g. "12500")
i have a ReportParameter object and i am working on number 2. it is tricky to get Spring to bind a command member to a flexible number of query string elements. i got it to work with a String[] in a test command object/ controller/ jsp. today, i was planning on trying to change the String[] to an ArrayList of ReportParameter obejects, something like this: http://www.jroller.com/page/Solomon?entry=tip_list_subselection_in_spring
tom
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- giving a report with parameters defined at design time it would be interesting to popup an isprompting functionality over the web to send parameter values to the report.
- having the possibility to change parameters over the web would be great, but the main thing for me is to send the parameter values to the reports in the http request. This is the main problem. In fact i see ussrp like a report repository able to load reports and try reports over the web. Then other applications can send parameters to the reports by the URL. It's like a report self-service.
I'm going to see your draft implementation and give u an answer.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I tried your supplement with params, it seems OK.
Few notices:
- the reloading when changing parameters must be set in the URL with reload=1.
- adding the type of parameter in the url seems ugly. It's not the job of the user to determine the type of parameter. The type is defined in the report design. So is it necessary?
- i insist saying it would be interesting autmaticaly detecting parameters in the report and then popup a window to fill the value of report parameter. Isn't it ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
we are on the same page. i agree that ussrp is best as a report repository responding to urls to load, look, run, print...
i like both of your param ideas.
to get the type from the jasperDesign we will need to match a queryString param name with the paramName in a jasperDesign. a function like JRParameter net.sf.ussrp.bur.Report.getParameter(String paramName) would probably do the trick...
prompting for params... ...let's think about this... ...a ussrp implementer may want one of three param-running behaviors for a param that they added to a report:
1 - prompt
2 - read value from query string
3 - use defaults
if we agree on the 3 options, it would seem that a flag would need to be used to determine if app behavior will be 1 or 3.
let me know what your thoughts are. if you would like to take one of these enhancements, let me know.
thanks!
tom
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm globally agree with u except for the following:
the flags u mention could control report behaviour and not only app behaviour. I mean, one should want to view a report after prompting parameters and another reading parameters in an URL.
The flag could be a property of net.sf.ussrp.bus.Report
Some other thoughts:
- it could be possible to retrieve parameters from jasperDesign, and the isForPrompting parameter too. If i assume these parameters are defined at design time these parameters have no longer sense because the webapp doesn't use it.
- i don't know exactly what is the better behaviour to assign to the flag ... My point of view is that just controling the bahaviour with the design parameters could be good but requesting a report with parameters directly with the URL would miss.
I would be glad to take one of theses enhancements when we'll be ok about the functionalities ...
Eric
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>The flag could be a property of net.sf.ussrp.bus.Report
nice idea, it is there, see next.
> it could be possible to retrieve parameters from jasperDesign
exactly - Report.getJasperDesign().getParameterList()...isForPrompting() will do the trick. The reason for the "Report" object is to wrap JasperDesigna and JasperReport and get them to persist correctly in the db.
...there are two designs that i can think of: JavaScript popup or an additional page. I like the popup better - you?
For the popup idea, you could add a member method like getParamsForPrompting() which would return a list of ReportParameter objects for prompting. myreports.jsp could have a javascript routine including a popup for each param and a window.document.location.href to send it on its way.
...that'll work great. i am adding some of that type of javascript now for a drill down reports page. ....big user of params...
i am working on your suggestion to remove type from the params query String. i am also working to make params move throughout the webapp. i will have everything you need done tomorrow.
I will commit the code and update on this thread tomorrow when I finish with the params. You will need to wait 5 hours for the anonymous cvs to be updated after I check in... Here is the cvs connect info (if you don't already have it): http://www.ussrp.com/cvs_connect.txt
thanks~
tom
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
main edit was to add ReportViewCommand.getParamMap(). only using JRDesignParameter now -- i will remove ussrp ReportParameter from cvs.
my comment on the popup idea looks more confused than anything else :-). ...i think what i was trying to say is that one option would be to simply make calls on Report.getJasperDesign().getParameterList() in myreports.jsp to create your JavaScript.
thanks again for pointing out that type did not belong in the query string.
tom
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
before adding anything i would like to take more time to see the how ussrp works.
Since yesterday i have more free time to work on ussrp.
So i hope to give something good for next release !?
Eric
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
i think for me a good evolution in ussrp would be the possibilty to add parameters to the reports, defining default values, and isForPrompting capabilities like in iReport.
I'll try to add these capabilities on my own.
I wanted to share this point of view with ussrp developers.
Eric
it would be great to see what you come up with. it is top on my list for me as well - maybe we can collaborate. here are a couple ideas:
1 - params are defined at report design time
2 - ussrp needs to provide a controller that can parse report parameters in a query string
3 - if ussrp had a ReportParameter object, it would need two Strings: 1 - type (e.g. "java.lang.Integer") and 2 - value (e.g. "12500")
i have a ReportParameter object and i am working on number 2. it is tricky to get Spring to bind a command member to a flexible number of query string elements. i got it to work with a String[] in a test command object/ controller/ jsp. today, i was planning on trying to change the String[] to an ArrayList of ReportParameter obejects, something like this: http://www.jroller.com/page/Solomon?entry=tip_list_subselection_in_spring
tom
here is a draft implementation that supports String, Integer and Image params:
http://sourceforge.net/tracker/index.php?func=detail&aid=1388588&group_id=150776&atid=778880
There is a zip file attached to the support request link... just a hack, but it works...
Hi,
Thinking once again to the problem i notice:
- giving a report with parameters defined at design time it would be interesting to popup an isprompting functionality over the web to send parameter values to the report.
- having the possibility to change parameters over the web would be great, but the main thing for me is to send the parameter values to the reports in the http request. This is the main problem. In fact i see ussrp like a report repository able to load reports and try reports over the web. Then other applications can send parameters to the reports by the URL. It's like a report self-service.
I'm going to see your draft implementation and give u an answer.
I tried your supplement with params, it seems OK.
Few notices:
- the reloading when changing parameters must be set in the URL with reload=1.
- adding the type of parameter in the url seems ugly. It's not the job of the user to determine the type of parameter. The type is defined in the report design. So is it necessary?
- i insist saying it would be interesting autmaticaly detecting parameters in the report and then popup a window to fill the value of report parameter. Isn't it ?
we are on the same page. i agree that ussrp is best as a report repository responding to urls to load, look, run, print...
i like both of your param ideas.
to get the type from the jasperDesign we will need to match a queryString param name with the paramName in a jasperDesign. a function like JRParameter net.sf.ussrp.bur.Report.getParameter(String paramName) would probably do the trick...
prompting for params... ...let's think about this... ...a ussrp implementer may want one of three param-running behaviors for a param that they added to a report:
1 - prompt
2 - read value from query string
3 - use defaults
if we agree on the 3 options, it would seem that a flag would need to be used to determine if app behavior will be 1 or 3.
let me know what your thoughts are. if you would like to take one of these enhancements, let me know.
thanks!
tom
Hi,
I'm globally agree with u except for the following:
the flags u mention could control report behaviour and not only app behaviour. I mean, one should want to view a report after prompting parameters and another reading parameters in an URL.
The flag could be a property of net.sf.ussrp.bus.Report
Some other thoughts:
- it could be possible to retrieve parameters from jasperDesign, and the isForPrompting parameter too. If i assume these parameters are defined at design time these parameters have no longer sense because the webapp doesn't use it.
- i don't know exactly what is the better behaviour to assign to the flag ... My point of view is that just controling the bahaviour with the design parameters could be good but requesting a report with parameters directly with the URL would miss.
I would be glad to take one of theses enhancements when we'll be ok about the functionalities ...
Eric
>The flag could be a property of net.sf.ussrp.bus.Report
nice idea, it is there, see next.
> it could be possible to retrieve parameters from jasperDesign
exactly - Report.getJasperDesign().getParameterList()...isForPrompting() will do the trick. The reason for the "Report" object is to wrap JasperDesigna and JasperReport and get them to persist correctly in the db.
...there are two designs that i can think of: JavaScript popup or an additional page. I like the popup better - you?
For the popup idea, you could add a member method like getParamsForPrompting() which would return a list of ReportParameter objects for prompting. myreports.jsp could have a javascript routine including a popup for each param and a window.document.location.href to send it on its way.
...that'll work great. i am adding some of that type of javascript now for a drill down reports page. ....big user of params...
i am working on your suggestion to remove type from the params query String. i am also working to make params move throughout the webapp. i will have everything you need done tomorrow.
I will commit the code and update on this thread tomorrow when I finish with the params. You will need to wait 5 hours for the anonymous cvs to be updated after I check in... Here is the cvs connect info (if you don't already have it):
http://www.ussrp.com/cvs_connect.txt
thanks~
tom
done.
main edit was to add ReportViewCommand.getParamMap(). only using JRDesignParameter now -- i will remove ussrp ReportParameter from cvs.
my comment on the popup idea looks more confused than anything else :-). ...i think what i was trying to say is that one option would be to simply make calls on Report.getJasperDesign().getParameterList() in myreports.jsp to create your JavaScript.
thanks again for pointing out that type did not belong in the query string.
tom
hi -
do you have anything that you would like to add to the ussrp 0.0.5 release? parameter pop ups?
thanks,
tom
Hi tom,
before adding anything i would like to take more time to see the how ussrp works.
Since yesterday i have more free time to work on ussrp.
So i hope to give something good for next release !?
Eric