Someone sent me an e-mail tonight wondering if I knew what Portlet filters would be like when they are finally defined in the JSR, and I'd like to share the question along with the answer I provided them with.
First, the question:
>read your article, very interesting indeed.
>There was one thing about the future of JSR-168 I didn't understand:
>What are theses filters? What benefit will they bring to portlet
Now, for the answer:
If you are familiar with Servlet filters, Portlet filters will offer similar functionality. The idea is that you can have some code react before and after the Portlet functionality. As an example, let say you build a Portal page that consists of a few Portlets, which should only be displayed if the user logs on. Now, how do you check to ensure that the user is still logged on and that the session has not expired yet? Furthermore, how do you prevent others from having to build this type of check into each of their portlets? And more so, what if you want to use unsecured portlets in a secured environment, when they haven't been coded in this manner? The answer is filters.
You can code up a separate code module that would inject itself both pre and post-call for Portlets. Getting back to the example above, in the Portlet's case, the filter can inject itself pre-call and check if the session is still active, and redirect the user to a particular portlet for logging the user back into the system.
What is unknown at this point is how the filters will work. My guess is that they'll provide pre/post filters for both action requests and render requests, respectively. This differs from servlets, since servlets only have one particular type of request (which is later broken up into get, post, delete, etc.).