Backdrop:
You want to allow your site visitors or customers to print documents without popping up a dialog box. You dont want to display a print dialog box because you feel it's a distraction or a devaition from normal website browsing flow. You're probably right in asking for a silent print feature in the browser object model, especially in the model provided by JavaScript (or any client side scripting language).
In this short article (that would be extended later on, depending on how many people read it and find it useful), I will detail why the browser model doesnt allow for silent printing , or automatic printing over an Internet-based website, with minimum or no user interaction.
Let's get into the details . . . . .
Basically, the job of the browser is to display webpages. Technically, this means that the browser is supposed to do only certain types of jobs - display HTML and allow for user-interaction with dynamic elements in the webpage. The browser is not allowed to do certain things by default - execute a snippet of code, download files that it doesnt understand or recognize, create system files that would execute in the background and log user activity.
You could extend the browser through plugins to do some of those jobs. You could write scripts in client-side scripting languages to perform "certain" tasks at the client's computer. But client side scripting languages would have limitations on what a scripter is able to command the client's browser to do.
That's purely because of the nature of the Internet - it's not a trusted zone.
What's a trusted zone ?
Well, basically it is a place where all the accessible resources are trusted by your computer (indirectly, you trust the resources at the place). It could be the local area network (so long as you're sure that your computer will be secure in it), or the network of your business associate or subsidary (as long as you chose to trust the resources availble on the foreign network).
So what's the thing with trusted zones and untrusted zones ?
Trusted zones as the name says are places trusted by the client. The resources in such a place are capable of interacting with the resources at the client's place. The degree of such interaction depends totally on the nature and degree of the trust. For example, you trust that executables residing on your own drive/computer are far more trustworthy than the ones you downloaded off www.hackers.com .
How does this affect automatic printing ? Or, why should this concern me ?
Code running in trusted environments have far more privileges than code running from an untrusted source. For example, executables in your computer are capable of deleting certain files from the hard disk, but code running in the browser will not be capable of doing so (until the user has granted that privilege). Printing, or better, automated printing requires that the end-user grant privileges to your code to access his/her printer (that's the user's printer not yours). The remote printer is a resource that belongs to the remote computer to which it is plugged into (even though, your office may have paid for it). To access the remote printer, it is required that the remote computer grant privileges to your code to access the remote printer.
Hell, I dont need privileges to access the remote printer. My boss says that the client trusts our website so the client should be able to print without any user interaction . Why I should believe you ?
There are websites out there that are capable of ruining your client's computer, so why not yours ? Is there anything special about your site ? And how does the client know that you are not using his printer to print advertisements (of no value to him) ?
And what is with the minimum user-interaction ? How are you so sure that the printer will always print the correct output ? What if something went wrong during printing ? Why does your client have a problem clicking a button in the print dialog box ?
The print dialog is there to -
- grant access to your instructions to issue a print command,
- allow the user to modify any necessary settings that are necessary for obtaining a successful printout.
I know of an environment where you're wrong !!
It's probably on ActiveX based websites. Nothing new there. ActiveX is known to be insecure, and is supported only on MS Internet Explorer. Dont be surprised if half of your users wont be able to access your website.
If you're talking about Java(not JavaScript), then again there is nothing new there. If you are able to produce a signed applet, then it is possible to automate the print process as much as possible. It's mileage depends on what libraries you are using, that is, how powerful the libraries are in their ability to access the printer options, and produce a clean printout with most of the settings provided by the programmer (that is, you) , and hence result in lesser user-interaction (because most of the settings are provided by the programmer).
There is also a possibility of Winforms applications being able to print over the Internet. Like the first option mentioned above, Winforms applications seems to work only on Microsoft Internet Explorer. Unlike ActiveX, Winforms applications written using the .Net framework are far more secure. The programmer can request for further privileges to be granted to the code during it's execution. So, if your program wants to access the printer, it must merely request for the necessary privileges. Of course, the user executing the program has to grant the privileges. But this is far better than having a code "lockout" - your code is unable to run because it cannot even request for such privileges; your client will have to explicitly make changes to his computer's configuration to allow it run.
What now?
Silent printing may be the tip of the iceberg. There are far more things that may not be possible using client side scripting languages. Most of them are not even things that should be solved using client side scripting. It's more an issue of whether people have analysed the business problem at hand, and have recognized that a browser based solution may not be the answer. Chances are that poorly architected and poorly designed solutions often call the limits of Javascript (and other scripting languages) into question. In most cases, the solution might be a Windows forms solution (or a background service or a cron job or . . . . . ), or sometimes a change in the business process (hah!).
1 comment:
RE: your conclusion
Absolutely, yes. BUT, also sometimes no.
From a programmer's perspective, there could be a much more logical business process that avoids these hurdles entirely - but if you go around suggesting to clients that they should change their business processes then you'll find that you don't get much business. ;)
There is certainly a place for defining practical business processes when developing applications for clients (DDD is a good example of this), but in 'RL' you'll find many clients are apprehensive/hostile towards these suggestions. Yes, this reflects badly on the client, but business is business.
The way I see it is this, either you're doing it wrong or your client is doing it wrong - if you're doing it wrong then you need to recognize that and fix the problem (you highlight this), but if your client is doing it wrong then you've got two options: 1) get them to change (risky), 2) hack up a solution - even if it ain't pretty - in the end, the client is the one paying you to make it happen - if you can't make it happen then don't take the job.
The reason I'm suggesting this is that I'm getting a slight sense of the "you're doing it wrong, plz change" vibe from this post - and in the practical business world this doesn't often work.
Otherwise, good post, enjoyed it! =)
Post a Comment