Skip to main content

[jsr362-experts:] CDI Ideas for Portlets

  • From: Martin Scott Nicklous < >
  • To:
  • Subject: [jsr362-experts:] CDI Ideas for Portlets
  • Date: Tue, 25 Mar 2014 17:02:17 +0100


Hi all,

I have been thinking that there might be things we could do with CDI beyond
what we have discussed so far. We might be able to use CDI or CDI concepts
to simplify the portlet programming model, at least for some cases.

Here are a few ideas that occurred to me. I don't know if they are
practical or implementable in this form, but if they are found to be
interesting, maybe we can morph them into something workable. Note that if
we were to adopt some of the ideas, I would see them as being in additions
to the "traditional" portlet programming model, not as replacements for any
portion of the portlet API.

1. Register portlet-related objects as injectable CDI beans. The basic idea
would be to register all objects that are currently defined through the
portlet tag library "defineObjects" tag as CDI named beans - renderRequest,
renderResponse, portletPreferences, portletSession, etc. Such beans could
be injected into portlet code or used within JSPs and Facelets.

It seems to me like it should be possible to implement this in a
straight-forward manner either in GenericPortlet.java or by defining a new
portlet API class to be implemented by the portlet container containing
@Produces methods corresponding to the objects that we want to make
available. The objects themselves could probably be request scoped even if
the underlying data or object has a longer lifetime.

2. "Bean-like portlets" -  Define CDI-like annotations that could be used
to mark bean methods as portlet methods. For example, we could define a
@PortletView tag to mark the method called to render a portlet view, define
a @PortletAction tag  to mark a method called to execute a portlet action,
etc. The portlet name that the method serves could be specified through a
mandatory annotation field. Additional information like portlet title, etc.
could be provided either through additional annotation fields or through
separate annotations.

 The portlet container would scan the portlet classes when the portlet is
loaded to find the portlet methods and call those methods in the
appropriate portlet phase. This would allow developers to write bean-like
portlets without subclassing GenericPortlet and either with no or with just
a minimal portlet.xml file.

It might be possible to use the CDI container implementation to do the
annotation scanning when the portlet is loaded ... need to investigate.

You could write code that looks like this:

=======
...
class MyPortlet {
    @PortletView
    public void view(RenderRequest req, RenderResponse resp) {
      ...
   }
}
=======

Supporting this programming style might make portlet writing more appealing
and intuitive for developers who are familiar with the CDI bean approach.

3. We have the item "Extend the portlet eventing capability" on the
official to-do list for JSR 362. The idea behind this item is support for
ad hoc events - events that do not need to be defined in the portlet.xml
file. CDI provides an ad hoc eventing capability. Maybe we could leverage
CDI event support, or at least its style, to provide such support for
portlets.

CDI allows events to be defined and fired like this, where @NameAdded is a
custom qualifier provided by the application that further specifies the
event type:
======
   @Inject @NameAdded
   private Event<String> nameAddedEvent;
   ...
   nameAddedEvent.fire("Bob");
======

Events are listened for (observed) like this:
======
   public void addName(@Observes @NameAdded String name) {
     ...
   }
======

However, CDI beans supported for a particular application have to all be
available through the class loader for that application. For portlets this
means that you cannot use the CDI event mechanism to send an event from one
portlet to another unrelated portlet.

The idea for portlet eventing support would be to basically allow CDI-style
events to be supported between portlets. We could define a portlet-specific
annotation @PortletEvent. The portlet container would identify all events
and all observer methods  annotated with @PortletEvent when the portlet is
loaded. When an event annotated with @PortletEvent is fired, the portlet
container would - in some tbd manner - get control and route the events -
in some tbd manner - to other portlets with matching observer methods. This
could be done, at least  for portlets on the same page, without wiring and
without  event declaration in the portlet descriptor.

This 3rd idea has for me the least clear path to implementation and may be
sort of questionable as to whether it fits & can be done. There would
almost certainly be WSRP impact that we would need to consider. It might be
better to define ad hoc events for the traditional portlet API first and
worry about how / whether to make them work as CDI events as a second step.

Thoughts?

regards,
Scott




[jsr362-experts:] CDI Ideas for Portlets

Martin Scott Nicklous 03/25/2014

[jsr362-experts:] Re: CDI Ideas for Portlets

andy . bosch 03/26/2014
 
 
Close
loading
Please Confirm
Close