I've been working on a few Java EE 6 applications using JSF 2.0 for a while now, and my experience with the default implementation within Glassfish 3.1 - Mojarra has left me wanting for more. One of my applications required a file upload widget. This is doable in Mojarra but requires a shim. I decided to create a spike implementation using PrimeFaces, since that apparently had a fileUpload component; the spike obviously being used to estimate the time I would require to port the application to PrimeFaces.
A few minutes later, and I managed to get a working example up and running. The example is based on several similar examples posted on the internet. I've attempted to document a couple of gotchas encountered.
The Source Code
This was my JSF page; it is quite simple. The fileUpload component was made available on adding the primefaces tag. Note the use of the h:head tag. Apparently, PrimeFaces will add scripts and stylesheet resources with the target value set to "head". If one uses the plain head tag from the xhtml namespace, then the scripts and stylesheets will not be added.
One can notice similarities between the above facelet and the one posted on the AMIS blog, which was followed during the spike.
The managed bean that processes the FileUploadEvent is quite simple. My current need of the hour was to extract the contents of the uploaded file into a byte array to persist into a BLOB in a database; this was duly supported by the UploadedFile class of PrimeFaces.
And finally, to top it off, here are the contents of the deployment descriptor and the resource bundle.
Deployment
PrimeFaces 2.2.1 depends on Commons FileUpload 1.2.1 and Commons IO 1.4 to provide the file upload functionality; one can find the details of the dependencies in the packaged pom.xml of the PrimeFaces distribution. Anyone using Maven will quite obviously not have to bother about this, but for those who do not, it is quite obvious that the files commons-fileupload-1.2.1.jar, commons-io-1.4.jar and primefaces-2.2.1.jar have to be placed in the WEB-INF/lib directory of the packaged WAR file, in case these are not provided by the container.
Wednesday, June 29, 2011
Sunday, June 18, 2006
Investment lessons in a single picture

Demonstrated to me by my banker friend Manmohan, at my new company. Fairly self explanatory.
Summarized as follows,
- The chance of higher earnings/profit increases with more riskier investments.
- The moment a person gets better earnings from an investment destination, the risk in investing w.r.t that destination virtually reduces, and it is wise to put in/ transfer more investments to that destination.
- The bulk of investments should be in the least risky of all investment destinations. It is generally better to put money in an investment destination where the principal amount is guaranteed to be returned. Direct equities and mutual funds are therefore not recomended as good investment destinations unless well understood.
Tuesday, April 18, 2006
iText + Google Calendar = Neat Printouts!!
Google Calendar (beta at time of writing) uses an Open Source library iText for printing calendars. The calendars are generated as PDF files that can be downloaded to the desktop or straightaway printed.
And this is for the programmers who work under pointy haired Dilberty bosses - the next time you're asked for internet based silent printing of PDF files, ask them to have a look at Google Calendar. You can't get more professional than that. Want anything better? You should think of writing your own proprietary browser (i.e a desktop app) or browser plugin or a Acrobat Reader plugin. Good luck buddy.
Technorati Tags: google+calendar, itext
Sunday, February 26, 2006
Adobe Acrobat 7.0 Browser Control Type Library (ActiveX or COM)
Update: Please check out the other PDF related links in the sidebar as well.
Some horrors are erased!! Gasp !!
I came across the Adobe Acrobat 7.0 Browser Control Type Library that could be used to display and print PDF files on desktop (Windows forms) applications [I haven't explored utilizing this in a webpage, so that will have to wait]. This is really good stuff for some people, for it is an ActiveX control that you could utilize to automate certain PDF-related actions, instead of relying on the AcroRd32.exe process commandline options or DDE messaging (or worse - Win32 programming).
However, every approach has it's pitfalls.
And someone's already had a problem -
And if you have funds, then take this advice from an ex-Adobe employee a bit seriously, for he says -
Here's the CodeProject article utilizing the Adobe Acrobat 7.0 ActiveX object for communicating with Acrobat Reader, along with the .Net example utilizing the Browser Type Library that is described in the comments.
Ok, want to know more about this library ? Hop on and download the Adobe Acrobat Inter-Application Communication (IAC) Reference from the Adobe site (pdf download). The Acrobat Browser Type Library is provided by the AxAcroPDFLib.AxAcroPDF object. This should be suitable for most of your needs. You can access it by adding a reference to AcroPDF.dll (that resides in the ActiveX directory under the Acrobat application directory) in your IDE environment.
Technical Notes
And to help people searching for solutions to common problems involving Adobe Acrobat (even Reader), I'm posting a link to Experts Exchange's set of time-tested Adobe Acrobat solutions.
Some horrors are erased!! Gasp !!
I came across the Adobe Acrobat 7.0 Browser Control Type Library that could be used to display and print PDF files on desktop (Windows forms) applications [I haven't explored utilizing this in a webpage, so that will have to wait]. This is really good stuff for some people, for it is an ActiveX control that you could utilize to automate certain PDF-related actions, instead of relying on the AcroRd32.exe process commandline options or DDE messaging (or worse - Win32 programming).
However, every approach has it's pitfalls.
And someone's already had a problem -
Bah. I can't believe that Adobe hasn't stepped up to hand out a library that will print any PDF with all of the printer settings available to be changed. (You apparently can create an Interop around their Acrobat TypeLib, but its features are limited and it can only print to the default printer.)
Oh well, that's why folks can charge lots of money for libraries I guess.
And if you have funds, then take this advice from an ex-Adobe employee a bit seriously, for he says -
I can give ya a little info on this as a former Adobe Employee and specifically dealing with Acrobat. They do have a SDK that allows you to work with PDFs but its not free, it does work in both managed and unmanaged code and they give some good examples done in C# and VB.net but here again its not free. I would look to some of the free PDF stuff and that may work but this is workable if you have the SDK because you can actually create a PDF object and load in that PDF and then use c# to print it like you would anything else.
Here's the CodeProject article utilizing the Adobe Acrobat 7.0 ActiveX object for communicating with Acrobat Reader, along with the .Net example utilizing the Browser Type Library that is described in the comments.
Ok, want to know more about this library ? Hop on and download the Adobe Acrobat Inter-Application Communication (IAC) Reference from the Adobe site (pdf download). The Acrobat Browser Type Library is provided by the AxAcroPDFLib.AxAcroPDF object. This should be suitable for most of your needs. You can access it by adding a reference to AcroPDF.dll (that resides in the ActiveX directory under the Acrobat application directory) in your IDE environment.
Technical Notes
- If you dont want to display the PDF document in a Windows Forms application, then you'll have to set the 'Visible' property to false. And if you want to send the PDF file directly to the printer, then you could use one of the methods provided by the control for that purpose - Print, PrintAll, PrintAllFit, PrintPages, PrintPagesFit. That should be suitable for your silent print needs in most cases.
- You could experience problems when you have to print to the default printer. The default printer seem to be determined by Acrobat when it is loaded, and not by Windows. So changing the default printer mid-way through your application's runtime might cause unexpected behavior.
- It is impossible to "name" / "determine" the printer that is used to print the document. Unless you don't want the user to access all the printer settings that could change the workflow, the only solution is to use the PrintWithDialog method (which is used to present the Acrobat Print Dialog Box that allows the user to make changes to the number of copies to be printed, or print to a file).
And to help people searching for solutions to common problems involving Adobe Acrobat (even Reader), I'm posting a link to Experts Exchange's set of time-tested Adobe Acrobat solutions.
Subscribe to:
Posts (Atom)