steele at laszlosystems.com
Sat Jan 29 06:07:50 PST 2005
This makes sense. I can see this being used in a few different ways:
- To create standalone static reports, that are configured within a
Laszlo application but displayed in a separate window (or tab). The
report (PDF or HTML) would display in a separate page; there aren't any
issues of how to display it inside a Laszlo application. Or, a CSV
file might be downloaded.
- To create a dataset that is displayed within a Laszlo application,
and can be further manipulated there --- for example, Laszlo controls
are used to change the sort order or filtering, but maybe some
manipulations go back to the server to request another dataset (a
- To request an HTML or image that is displayed within the Laszlo
application. (Or --- with a huge amount of work -- PDF.)
On Jan 28, 2005, at 10:32 AM, Martin Wegner wrote:
> IMHO JasperReports can be difficult to learn at first but it is well
> supported and very powerful. Using it within Laszlo would really be a
> boon for printing from web apps. I think advanced users would find it
> be another reason to use Laszlo (as if there aren't enough already).
> --- Chris Lyman <clyman at apprenticeis.com> wrote:
>> Hi All,
>> I need your help in a reality check regarding printing. What I'm
>> currently looking at is JasperReports, or some derivation there of.
>> I see it, the flow would be something like this:
>> 1) The designer/developer creates the template for the printed page
>> using one of the various banded report creation software products (a
>> of which run in Eclipse). The output is XML and I'm guessing that it
>> would be possible to insert certain meta tags that would be filled in
>> the Laszlo client runtime. i.e. <![CDATA[LPSBoogie:UserName]]>
>> 2) The user requests an app that will utilize the printing feature.
>> The user does his or her thing with the app. Once the app is ready,
>> will request the raw report file. The app will then parse the xml
>> and look for the special meta tags. It may be easier to do this
>> actually creating the XML object, just work over the string. The app
>> then passes back the modified report to the server.
>> After the app has done its thing, it passes back the user fields to
>> server via a JSP page. Then the JSP either creates a datasource for
>> JasperReports or modifies a copy of the report.
>> 3) The server then does its magic and creates a well formatted file,
>> which can then be downloaded by the client or the user.
>> Two immediate issues I see are the preclusion of the ability to
>> free form printed reports on the fly. This may or may not be an
>> I don't know if people really want to free form printed pages.
>> have any input?
>> The other issue is dealing with the return product. The resultant
>> report would be PDF (PostScript), HTML, XLS, CSV or XML. Meaning that
>> either the browser would be used to deal with the file OR some sort of
>> page parser would have to be built into the Flash runtime.
>> Let me know what you think. Is this even the direction that we want
>> go? Or do we want to do everything client side?
>> Best Regards,
>> Laszlo-dev mailing list
>> Laszlo-dev at openlaszlo.org
> Laszlo-dev mailing list
> Laszlo-dev at openlaszlo.org
More information about the Laszlo-dev