Mis-using applets?

[Brian Jennings]

Hi, I wanted to describe a problem I'm trying to solve and see if I'm taking the wrong approach.

I'm new to applet and JSP programming so am not familiar with the best way tro solve this.

Basically I'm changing an existing system that uses a JSP generated front end and a mainframe back end running COBOL/CICS. Currently a report is generated in COBOL (at the request of a JSP screen) and sent to a spool on the mainframe for printing. I want to move the printing function into the JSP.

The way I want to do this is have the report output returned to the JSP in a bean and have the JSP call an applet that would send the report to the default printer.

Funny thing about the applet is, I do not want to display it. I simply want the jsp to pass the data and have the applet silent print. Is this an appropriate use for an applet? Is there a better way of accomplishing this? Can I even have an applet that is non display?

I thoght I could simply create a static method in the applet and have the JSP call this method. I'm not sure this would even work really. I just don't know the web programming structure well enough.

Thanks for your time.

[Ulf Dittmer]

It's possible to have non-visible applets (just give it a size of 1x1 pixels). What's not possible is "silent printing". In order for an applet to be allowed to print, it needs to be signed - which means the user will be asked to accept the security certificate. Once he's done that, the applet can proceed as it sees fit, including printing to its heart's content.

Can't you show the report as part of a web page, and thus make use of the browser's print functionality? That wouldn't be silent, either, though - the user would at least be shown the print options dialog.

[Brian Jennings]

Thanks for your reply.

It's fine that the user will have to click on the security pop-up. We are printing a cheque and the user has to set up the printer with cheque stock. We don't want them to be able to print more than one copy though(or choose a different printer), so no, we can't display the report, or store it, or display the print dialog.

We want the report to be sent to the printer on the users request, with the users knowledge.

Is calling a static method in a non display applet apropriate use. Since the report is in a bean, the applet won't retain a copy of the report, correct? If I'm using a static method for printing, does the applet even have to be initialised?

I'm only using an applet so I can have access to the local printer, security certificate prob lems aside. Is this a reasonable use for an applet?

Thanks

[Ulf Dittmer]

Since the report is in a bean, the applet won't retain a copy of the report, correct? If I'm using a static method for printing, does the applet even have to be initialised?

Correct, the applet wouldn't have to implement any of the lifecycle methods, and there'd be no trace left once the user closed the page containing the applet.

I'm only using an applet so I can have access to the local printer, security certificate prob lems aside. Is this a reasonable use for an applet?

I'd stay away from such a solution, since applets often introduce more problems than they're worth. And it would still not be foolproof, since the user could have set up the default printer to print to a PostScript file - thus enabling unlimited printing of copies of the check.

[Brian Jennings]

Thanks again for the reply.

What would your solution for this be?

Currently they are using a third party application to pull the report off the mainframe spool queue and send it to their printer, so in that respect the problem already exists. We jsut want to eliminate the third party application.

The users are all within our organization. This is not open to any shmo on the internet.

[Ulf Dittmer]

I'd look into beefing up the printing infrastructure so that a server-side process could print directly to wherever the output is desired, thus avoiding the client-side printing issues. But it does sound like a viable approach for your situation.

[Ernest Friedman-Hill]

Note that a JSP can't directly call a method on an applet; the JSP's Java code runs on the server, while the applet runs on the client. The applet might do something in its init() method when first loaded, but otherwise any method calls would have to be done via Javascript, adding to the complexity and introducing a fraud vector (if multiple-printing is a security issue).

[Ulf Dittmer]

True, a better approach would be to put all required data into <param> tags inside of the <applet> tag, so that the applet can operate autonomously w/o the need to start it explicitly.