I have an existing swing desktop application that I wish to convert to a web application. The first thing that is stopping from doing so is that the desktop application deals with writing and reading from PDF files. Also the user fills up the PDF forms which needs to be read by the application.
Now a typical use case in the desktop application is like, the user logs in opens a PDF form and fills it up. The swing application manages where the file is stored so it goes to the file and reads the form, extracts the data and stores the data in the db. The user might not fill up the form all in one go. He might save it come back to it later and continue.
All of this needs to be done by the web app now. My problem is I don't want the user to download and upload the form multiple times to the server. That would eat the bandwidth and also asking the use to save the file locally and upload it back once he completes filling the form doesn't appeal to me since the desktop application nicely used to manage the location of these files as well.
Would I need to implement something like a dropbox kind of thing? A small deamon running continuously to check what file has been updated and upload it to the server? That would be difficult since at the server I wouldn't know if the file was latest or not. Is there anything like this that someone might have done before?
I have anther suggestion: why don't you show the user a form with the same fields and transfer them to the PDF after the user submits. This way the Pdf does not leave the server and you transmit just the minimal amount of data.
Switching to a web-version of the application may force you to re-think some of the way you are doing things. Certainly browsers are intentionally limited in their access to the local file system which introduces a major hurdle for your current mode of operation.
Even if you could display the PDF within a browser, detect the completion of edits and send this back to the server from within browser code (which is probably possible), you'll be subject to different browsers doing different (strange) things with whatever pdf plugin is installed.
As Vitaliy mentioned already, switching being able to populate a (web) form in the browser means that whole download upload problem goes away. But then you have to take what the user has done in a web page and pump that into a PDF somehow. If you don't HAVE to start with a PDF, but could collect the data and produce a PDF at the end then you might have more options. For example you could use iText to create a PDF directly if you don't have too many styles of document to work with. You could use something like Docmosis which you can give templates to and get it to populate and render PDFs later. With the Docmosis option you can also ask Docmosis for the list of fields in the template so could build a web form based on the selected template, let the user fill it in, then push that data to Docmosis to produce the file.
Hopefully there's some options there that are useful to you.
Adobe documents how to do this here. Never underestimate the power of design-by-google. I know this can be made to work because I've used PDF forms on line.
I worked on a similar issue a few years ago, although I wasn't dealing with signed forms. The signature definitely makes it a little more difficult. However, I was able to use iText to create a PDF form with fields, and only submit the field data back to the server. Offhand, I unfortunately do not remember exactly what/how we did it, but can confirm it is doable (with limitations/caveats). Ex: User had to have PDF reader plugin installed & User was forced to d/l the pdf every time.
Basically what I did was use iText to create an FDF from a PDF (with form existing form fields). The submit button in the FDF actually submits the form data to a URL of your choosing (not unlike an HTML form). Once you have that data, I believe I merged the form fields (from the FDF) with the PDF on the server side using iText.
Once you use the server to maintain all the form data, the synchronization/locking process you use to ensure that a single user is updating the latest and greatest form data is up to you.
Your comment under jowierun indicates that you want to deal with word/excel/etc docs as well, so I am not entirely sure I am understanding your needs. Your initial post discussed the needs to fill out PDF forms locally, but afterwards it sounds like you are looking for a file-sharing system instead.
Can you please clarify exactly what you are trying to accomplish?
Related
I need to allow for csv-file downloads on my page and I was going to try ngCsv (from Angular) but for browser support this seems fairly limited. I've seen quite a few examples of this being done with vanilla Javascript. And after a discussion with a colleague of "backend vs. frontend" I'm feeling more and more unsure of what to do.
Are there any true optimization/efficiency reasons why I should avoid doing this on the client side (assuming the files are no more than 100MB each download)?
Are there any true optimization/efficiency reasons why I should avoid
doing this on the client side (assuming the files are no more than
100MB each download)?
If the data on the .csv would be the same for each user, and only updated every now and then, I would suggest you have your server create / update a static .csv. It wouldn't be resource-intensive, and you wouldn't have to worry about browser compatibility / user resources.
If, however, the data you need to create a .csv for is different on a per-user basis, then you should consider creating the file client-side. If you can help it, you don't want your server having to dynamically generate 100MB .csv files each time a user clicks the link.
You could write a script that only generates the .csv client-side if the browser is not mobile and there is web-worker support. If either of those conditions are not met, you could fall back to having your server do it.
Ultimately, your answer is going to really depend on the requirements / context of this project. Try to cache the results where possible, and use common sense. Good luck :)
I want to make an functionality in which user can share the url of uploaded PDF. Now when the another user open the same pdf with given url, first person will scroll down and on another user can see the scrolled content directly or the pdf will be automatically scrolled.
Is it possible using Java, JavaScript or another technology?
Ex. Person 1 has shared exaple.pdf with person 2 by giving link of it.
Person 2 had clicked on link and the pdf is opened at his side.
Now person 1 is scrolling the pdf to page no. 3 and at the same time on the Person 2's screen the pdf will be auto scrolled to page no. 3.
Please let me know if my issue is still not clear.
If I were you I wouldn't definitely use PDF format because it's really hard to manipulate with. Instead of that, you could make your a document a HTML file and then listen to page events with JQuery (like scroll event). So far so good, this is the easy part.
Now you need to make clients communicate with each other so I think WebSocket is the best way for it. If you insist on Java, you can use brand new WebSocket API but it can be also implemented in pure JavaScript like Socket IO so you don't even have to use Java for it.
But if you have to work with PDFs, then good luck, it's going to be really tough task.
As Petr Mensik said it would be probably pretty hard to do it with PDF file with Java, JavaScript.
But if you really want I guess it would be appropriate to check some Adobe SDK. I'm not sure but maybe Adobe AIR or Flex or other Flash application.
Requirement is to keep a copy of complete web page at server side same as it is rendered on client browser as past records.These records are revisited.
We are trying to store the html of rendered web page. The html is then rendered using resources like javascript, css and image present at server side. These resources keep on changing. Therefore old records are no longer rendered perfectly.
Is there any other way to solve above? We are also thinking converting it into pdf using IText or apache FOP api but they does not consider javascript effect on page while conversion. Is there any APIs available in java to achieve this?
Till now, no approach working perfectly. Please suggest.
Edit:
In summary,requirement is to create a exact copy of rendered web page at server side to store user activities on that page.
wkhtmltopdf should do this quite nicely for you. It will take a URL, and return a pdf.
code.google.com/p/wkhtmltopdf
Example:
wkhtmltopdf http://www.google.com google.pdf
Depending on just how sophisticated your javascript is, and depending on how faithfully you want to capture what the client saw, you may be undertaking an impossible task.
At a high level, you have the following options:
Keep a copy of everything you send to the client
Get the client to return back exactly whatever it has rendered
Build your system in such a way that you can actually fetch all historical versions of the constituent resources if/when you need to reproduce a browser's view.
You can do #1 using JSP filters etc, but it doesn't address issues like the javascript fetching dynamic html content during rendering on the client.
Getting the client to return what they are seeing (#2) is tricky, and bandwidth intensive.
So I would opt for #3. In order to turn a website that renders dynamic content versioned, you have to do several things. First, all datasources need to versioned too. So any queries would need to specify the version. "Version" can be a timestamp or some generation counter that you maintain. If you are taking this approach, you would also need to ensure that any javascript you feed to the client does not fetch external resources directly. Rather, it should ask for any resources from your system. Your system would in turn fetch the external content (or reuse from a cache).
The answer would depend on the server technology being used to write the HTML. Are you using Java/JSPs or Servlets or some sort of an HTTPResponse object to push the HTML/data to the browser?
If only the CSS/JS/HTML are changing, why don't you just take snapshots of your client-side codebase and store them as website versions?
If other data is involved (like XML/JSON) take a snapshot of those and version that as well. Then the snapshot of the client codebase as mentioned above with the contemporary snapshot of the data should together give you the exact rendering of your website as at that point of time.
A very resource-consuming requirement but...
You haven't written what application server you are using and what framework. If you're generating responces in your own code, you can just store it while generating.
Another possibility is to write a filter, that would wrap servlet's OutputStream and log everything that was written to it, you must just assure your filter is on the top of the hierarchy.
Another, very powerfull, easiest to manage and generic solution, however possibly the most resource-consuming: write transparent proxy server staying between user and application server, that would redirect each call to app server and return exact response, additionally saving each request and response.
If you're storing the html page, why not the references to the js, css, and images too?
I don't know what your implementation is now, but you should create a filesystem with all of the html pages and resources, and create references to the locations in a db. You should be backing up the resources in the filesystem every time you change them!
I use this implementation for an image archive. When a client passes us the url of an image we want to be able to go back and check out exactly what the image was at that time they sent it (since it's a url it can change at any time). I have a script that will download the image as soon as we receive the url, store it in the filesystem, and then store the path to the file in the db along with other various details. This is similar to what you need, just a couple more rows in your table for the js, css, images paths.
I am working on a web application developed in Java with struts running on Tomcat. I have a requirement in the web application as follows:
One JSP page having a list of PDF files each associated with a checkbox. The JSP page has one Button. Once the user selects the PDF documents he wants to print by selecting the associated checkboxes, user clicks on the button.
Then all the selected PDF docs should be sent to a specific local Printer( i.e. printer connected to the client machine where from user is accessing the web application). The selected PDF files should not be opened either in acrobat reader or in browser. The PDF docs should not be visible to the user while being sent to printer.
Could anyone please help me in implementing this requirement?
It is possible with Internet Explorer and ActiveX. Search about "auto print" and "silent printing" with Google. You may have to lower security settings in Internet Explorer for that.
We're using it here for some Intranets from our Customers.
For Firefox you may be able to trigger the print dialog via javascript. (http://stackoverflow.com/questions/975652/silent-print-a-embedded-pdf)
If this is the case you can disable print dialog in FF with setting print.always_print_silent=true in about:config.
Never did it on my own, so I cannot say for sure if it works like the ActiveX thing does.
For Chrome there is an issue requesting same feature like FF has. See https://code.google.com/p/chromium/issues/detail?id=31395.
You will most likely have to use a Java Applet for this. The browser have no inherent capability to print a pdf document. You may be able to access the "standard" adobe plugin, but to my knowledge it is not exposed to the standard scripting environment.
You can look here: Can a Java Applet use the printer?
Note: it is recommended to have the applet signed to prevent security restrictions and/or annoying questions to the user to allow access to printer.
You'll also need some form of PDF renderer in your applet (to render to printer). Something like http://java.net/projects/pdf-renderer/, read more here: http://juixe.com/techknow/index.php/2008/01/17/print-a-pdf-document-in-java/
That is not possible with JavaScript. It is possible with either Flash or a Java applet. In either case, you will need to be able to use both the Printer drivers and a custom PDF reading toolkit. There are adequate plugins for both for PDF reading, and both come with a printing API.
If I may say so, this is a bad requirement -- it is not good to force a user to print a document without reading it -- and should be re-negotiated, especially since it is trivially simple to have those documents print to PDF anyway.
You may all have seen online content management systems or publishing platforms, where one can edit a page, but for convenience, the editing is not done in the browser, but instead in Microsoft Word. So whenever you open the page to edit it, the current page is send to MS Word and after completing the editing, Word sends back the page to the server.
A good example is Confluence. Instead of using the built-in WYSIWYG editor, you can also edit a page in MS Word.
How does this work technically? I want to program something similar on a Java servlet based web app. The first part is easy. I convert my page into the format of the external application and send it to the browser setting the correct mimetype. The external application will open the document. But I have no idea how the second part works. How does this application sends the file back?
Please send me any pointers you might have. My main problem is probably that I really don't know what I should search for. Also, if you know any opensource Java based projects doing something similar, I would like to study them to get started.
PS: Please feel free to change the title of this question!
One way this works is if you start Microsoft Word not wih a file as an argument, but witha n http/https URL that points to a WebDAV-supporting location. In this case Word will send the file bach witha PUT method when saving.