By: Henrik Bentel - hbentel
Localization
2004-09-29 16:24
Hi
I've search earlier posts about localization and I have a question about that.
My goal is dynamic localization where the formatting of fields or variables is done at runtime. Let's say my application servers multiple locales concurrently at runtime, on a per user basis. I'd like different formatting time,dates,etc. based on locale. And since I'm lazy, I was hoping JasperReplrts would come to the rescue.
Currently it seems the only way to do it by passing in the locale as a parameter and using textExpression to instanciate SimpleDateFormat or Numberformat, passing in locale as parameter.
Is this assumption correct? alternatives?
Another question/request is the ability to set the locale used for a report on a per JasperReport instance. Somewhat ties into the above. Currently it seems the locale used is the default locale which is per JVM. Somehow set the locale used for the report as a attribute of JasperReport element in the template or progammatically at runtime. I assume this would be complicated by java scripting in the report, as beanshell probably just does what it does.
Just to throw that one out there.
thx,
Henrik Bentel
By: John Armstrong - siberian1967
RE: Localization
2004-09-30 08:18
Depending on your appserver you can make this easier.
For example, I use Struts running under Tomcat and generate reports from this environment.
What I do is set all of my dynamic parameters into a Hash and pass that hash into my report.
The report then accesses all of its localized fields directly from the hash. Since the app server created the hash and properly handled the locale at that level my report comes out fully localized, language, dates, currencies and strings.
This may not be 100% optimal but its created a really flexible and easy to use situation for us, allowing the struts app (which does great localization) to control the report.
By: Teodor Danciu - teodord
RE: Localization
2004-09-30 09:16
Hi,
I think there will be a REPORT_LOCALE built-in
parameter that could be supplied when filling the report.
This approach has the advantage that it does not
require us changing or adding new signatures for the
report filling methods.
All built-in formatters (the ones that use the "pattern"
attribute of text fields) will work with this parameter
which will have the current locale as default value.
Thank you,
Teodor
By: Edgar Dollin - edollin
RE: Localization
2004-09-30 10:08
This doesn't have universal applicability unless Jasper is aware of the container session and for most of my uses would not help.
Jasper really needs a run time framework. Many of us have put together pieces of one. Purhaps we can coalese these efforts and get a standardized one.
I have a project which addresses a jasper struts under njmvcopensource and would be willing to contribute code to a more complete project. There is another project on sourceforge targeted at webworks as well.
Edgar
By: John Armstrong - siberian1967
RE: Localization
2004-09-30 10:29
Why not? There is no dependancy on the session, I populate a Hash from my application and pass that hash in. The report never calls back to the app, it just accesses the hashtable to get data for display and calculations.
The hash has all my localization info in it including strings, locale etc etc.
I've used this from within struts, tomcat and stand-alone apps.
Probably missing your issue but for me this has worked well.
By: Henrik Bentel - hbentel
RE: Localization
2004-09-30 16:40
I agree about a more complete run time framework.
Question is if it should be under jasperreports or a separate project. But that is really what openreports(the existing run time project) is.
I've done something similar to openreports, but I used struts,spring instead of webwork, xwork.
Nothing wrong with openreports, I just wanted to see how to do it struts/spring way.
On the other hand, are we currently better off spending available time improving jasperreports? better jasperreport -> more users -> bigger community -> more contributions -> better jasperreports(maybe)
just a hmmm.....
By: Teodor Danciu - teodord
RE: Localization
2004-10-02 03:47
Hello,
Making a runtime framework is useful but is not
what JasperReports stands for.
In my opinion, the library should continue
to focus on what it does best, and that is rendering
documents from a report template and data source.
It's true that these days everybody get to make
makes its own such frameworks, but I think they
will still do this years from now since there seems
to be no framework that suits everybody's needs.
Starting to improvise on runtime frameworks will
only dilute the project since there are other
specialized projects that already provide this.
Thank you,
Teodor
Localization
2004-09-29 16:24
Hi
I've search earlier posts about localization and I have a question about that.
My goal is dynamic localization where the formatting of fields or variables is done at runtime. Let's say my application servers multiple locales concurrently at runtime, on a per user basis. I'd like different formatting time,dates,etc. based on locale. And since I'm lazy, I was hoping JasperReplrts would come to the rescue.
Currently it seems the only way to do it by passing in the locale as a parameter and using textExpression to instanciate SimpleDateFormat or Numberformat, passing in locale as parameter.
Is this assumption correct? alternatives?
Another question/request is the ability to set the locale used for a report on a per JasperReport instance. Somewhat ties into the above. Currently it seems the locale used is the default locale which is per JVM. Somehow set the locale used for the report as a attribute of JasperReport element in the template or progammatically at runtime. I assume this would be complicated by java scripting in the report, as beanshell probably just does what it does.
Just to throw that one out there.
thx,
Henrik Bentel
By: John Armstrong - siberian1967
RE: Localization
2004-09-30 08:18
Depending on your appserver you can make this easier.
For example, I use Struts running under Tomcat and generate reports from this environment.
What I do is set all of my dynamic parameters into a Hash and pass that hash into my report.
The report then accesses all of its localized fields directly from the hash. Since the app server created the hash and properly handled the locale at that level my report comes out fully localized, language, dates, currencies and strings.
This may not be 100% optimal but its created a really flexible and easy to use situation for us, allowing the struts app (which does great localization) to control the report.
By: Teodor Danciu - teodord
RE: Localization
2004-09-30 09:16
Hi,
I think there will be a REPORT_LOCALE built-in
parameter that could be supplied when filling the report.
This approach has the advantage that it does not
require us changing or adding new signatures for the
report filling methods.
All built-in formatters (the ones that use the "pattern"
attribute of text fields) will work with this parameter
which will have the current locale as default value.
Thank you,
Teodor
By: Edgar Dollin - edollin
RE: Localization
2004-09-30 10:08
This doesn't have universal applicability unless Jasper is aware of the container session and for most of my uses would not help.
Jasper really needs a run time framework. Many of us have put together pieces of one. Purhaps we can coalese these efforts and get a standardized one.
I have a project which addresses a jasper struts under njmvcopensource and would be willing to contribute code to a more complete project. There is another project on sourceforge targeted at webworks as well.
Edgar
By: John Armstrong - siberian1967
RE: Localization
2004-09-30 10:29
Why not? There is no dependancy on the session, I populate a Hash from my application and pass that hash in. The report never calls back to the app, it just accesses the hashtable to get data for display and calculations.
The hash has all my localization info in it including strings, locale etc etc.
I've used this from within struts, tomcat and stand-alone apps.
Probably missing your issue but for me this has worked well.
By: Henrik Bentel - hbentel
RE: Localization
2004-09-30 16:40
I agree about a more complete run time framework.
Question is if it should be under jasperreports or a separate project. But that is really what openreports(the existing run time project) is.
I've done something similar to openreports, but I used struts,spring instead of webwork, xwork.
Nothing wrong with openreports, I just wanted to see how to do it struts/spring way.
On the other hand, are we currently better off spending available time improving jasperreports? better jasperreport -> more users -> bigger community -> more contributions -> better jasperreports(maybe)
just a hmmm.....
By: Teodor Danciu - teodord
RE: Localization
2004-10-02 03:47
Hello,
Making a runtime framework is useful but is not
what JasperReports stands for.
In my opinion, the library should continue
to focus on what it does best, and that is rendering
documents from a report template and data source.
It's true that these days everybody get to make
makes its own such frameworks, but I think they
will still do this years from now since there seems
to be no framework that suits everybody's needs.
Starting to improvise on runtime frameworks will
only dilute the project since there are other
specialized projects that already provide this.
Thank you,
Teodor
0 Answers:
No answers yet
