Application developers who are new to portlet development get excited about the various new concepts available to them that makes software development easier. The facilities for resource serving in the JSR 286 API (Portlet 2.0 Specification) make performing AJAX requests incredibly simple, event processing makes creating collaborative portlets incredibly easy, and of course, the PortletPreferences object makes personalizing portlets on a per-user basis a lead-pipe-cinch. But it's those PortletPreferences you need to be warned about. As any experienced portlet developer will tell you, you should never, never, ever use PortletPreferences.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
The hidden danger of PortletPreferences
Okay, telling you to never use PortletPreferences may be a somewhat over the top statement. There are actually some good uses for PortletPreferences. The problem with PortletPreferences is the fact that the object is so overly used in a typical development environment that it is a better strategy to first assume that PortletPreferences are not a good tool in your portlet development toolkit, and only choose to use them when you have concluded beyond a shadow of a doubt that there is no better place to store information about your user.
The PortletPreferences object provides the ability to store information persistently about how a client wants to use a particular portlet. For example, with the weather portlet, a user can provide postal code information to the portlet, and the portlet will store that information persistently using the PortletPreferences object. The next time the user visits the view mode of the portlet, the weather for that user's postal code will be displayed. Persistently storing this information, and tying the corresponding data to the user and the portlet, is all done behind the scenes for you by the portal framework. This all sounds good, right?
Well, ask yourself this: how does the portal server save PortletPreferences information? Does it write it to the hard drive? Does it write it to a small, big-data store like MogoDB? Does it store it in 16 kilobyte blocks in a DB2 database? Well, the answer is, most portal developers and systems engineers don't know. How PortletPreferences data is stored is completely up to the portal vendor. The portlet developer, and for that matter, the database or portal administrator, has very little control over it. Go ask a database administrators what they think about having very little control over data. They won't like it; and neither should you.
Thinking about application efficiency
Imagine you stored a true/false flag in PortletPreferences. PortletPreferences isn't likely storing that as an efficient boolean value in a database. The information is probably being turned into character data, or a CLOB, or something very inefficient. If you wrote a little program to store that true/false flag in your own database, you could use a boolean datatype, and consume only one tiny bit of drive space, as opposed to the overhead of using some large and unwieldy character type that the portal likely uses.
Furthermore, how do you mine information stored to PortletPreferences? Imagine you had a little tax portlet, that estimated a user's tax burden, based on their income. Imagine you stored the user's income as a PortletPreference. How would you go back and mine that income data? If your boss comes to you and says "You know how we keep track of a user's income in that tax portlet you created? Well, I'd like a list of all the users with income greater than $100,000 a year. Get it to me this afternoon." How are you going to do that?
Surrendering control of your data
If you don't know how the portal stores your PortletPreferences data, and you don't know how the portal ties a particular preference to a particular user, you're going to have a pretty hard time mining your own data. And in a world where information is power, you are giving up a lot of power when you hand your data over to the PortletPreferences object.
PortletPreferences are great when used for what they are intended: a simple, configurable, portlet preference. If a user wants their portlet to have a pink background color, then store that information in PortletPreferences. If a user wants a 14 point font, store that information in the PortletPreferences object. If the user wants to tell you where they live, or how much money they make, well, that's something you should really hesitate to store as a PortletPreference.
When a software developer or portal solution architect chooses to store information in the PortletPreferences object, they are giving up control over where the data is stored, how the data is stored, and how easy it is to potentially mine that data in the future. That's a whole lot of control to be giving up, and smart developer know that better options are available.
Do you have any quick tips for mastering Portlet API development?Let us know