Page Comparison

This location is a place to document proposals, plans, and work-in-progress for the Jasig Notifications Portlet.  Initially this page contains ideas stemming from a lively breakout session at the 2013 Apereo Unconference in Phoenix, AZ.

Step-By-Step Plans

1. Branch the current codebase as rel-1-0-patches;  this will be the home of incremental work on the JSR-168 Notifications portlet (if any)
2. Update the version number in master to 2-0-0-SNAPSHOT;  this will become the JSR-286 Notifications portlet
3. Refactor the API for data sources based around INotificationService;  it just needs some polish
   
   1. Notification data elements that receive special treatment in the UI should be strongly-typed, meaning they have dedicated getters & setters that return the appropriate Java type
      
      • Title
      • URL
      • Due date
      • Body
      • Image (e.g. logo)
      • Severity
   2. Other data elements should be weakly-typed, meaning they don't have dedicated getters & setters;  there should be a public Map<String, List<String>> getAttributes() method that allows the notification to carry open-ended data from the data source
   3. This data is pass-through as far as the portlet Java code is concerned;  the data source needs to know about it, and the view layer (JSPs) needs to display it reasonably, but other components within the portlet don't need to understand its nature
   4. The portlet will continue to promote the design principal for supporting notification data it adopted from the outset:  Very few elements are required (possibly only Title), and the view layer gracefully displays what it receives and ignores what it doesn't
4. Transition the Emergency Alert portlet out of the Jasig Widget Portlets into the Notifications portlet;  this is a more suitable home for it;  that means wiring it to the Notifications API for data sources and (ultimately) deprecating it in its original location;  the Emergency Alert portlet includes a usable RSS-based data source implementation, so that will have to be moved as well
5. Define a couple JSR-286 Portlet Events:  one for broadcasting interest in notifications (requesting them), and another for receiving them;  this setup will allow any portlet in the portal to feed items to the Notifications portlet;  the design is similar to the uPortal Search API
6. Implement a concreate Notifications data source capable of receiving these events and feeding them to the portlet UI
7.  Code for receiving the broadcast event and sending the response event could be written & placed in a sub-module of Notifications;  this code would make implementing the system dead-simple for other portlets.  (awills 2013/02/27:  This item looks like less of a good idea now that we're at the point)
8. Implement support for this event-based API in the Jasig Announcements portlet that would (at a minimum) return announcements in the EMERGENCY category;  we would then display these in the Emergency Alerts portlet
9. Bundle versions of both Notifications & Announcements that contain these features with uPortal and configure them appropriately to showcase the EMERGENCY category -> Emergency Alert use case

Other Road Map Items

...

area of the Notifications wiki contains documentation related to new features, bug fixes, improvements, etc. that are proposed or in-progress.  Individual initiatives are captured in child pages.