Prima di iniziare, è necessario completare l'Esercizio 1.1: Importazione delle risorse.
In questo esercizio verranno illustrate le differenze concettuali tra le due API per portlet.
IBM portlet API è stata inizialmente sviluppata per WebSphere Portal Versione 4. Il supporto per JSR 168 portlet API è stato fornito a partire da WebSphere Portal Versione 5.0.2.
JSR 168 portlet API è una specifica di portlet JavaTM standardizzata, sviluppata da un gruppo diretto in maniera congiunta da IBM e Sun, con il contributo dei principali fornitori di server di portale. Lo scopo è quello di risolvere le problematiche di compatibilità tra i server di portale dei diversi fornitori. La specifica iniziale è stata approvata nell'ottobre del 2003.
WebSphere Portal supporta entrambe le API. Fornisce due contenitori di portale: uno legacy per IBM portlet API (di qui in avanti denominato portlet IBM) e un contenitore standard per JSR 168 portlet API (di qui in avanti denominato portlet JSR 168). I portlet in esecuzione in contenitori differenti possono risiedere nella stessa pagina di portale.
Un contenitore di portale fornisce l'ambiente di runtime per i portlet. Supporta il ciclo di vita dei portlet, che consiste di tre fasi:
La fase gestione delle richieste si suddivide a sua volta nelle seguenti fasi:
Prima di esporre le specifiche differenze di codice, è necessario comprendere alcune differenze tra le due API per portlet.
Non occorre lavorare direttamente con il codice di origine relativo ai descrittori di distribuzione del portlet come descritto di seguito; infatti, l'editor del descrittore di distribuzione portlet fornisce un'interfaccia utente grafica per portlet.xml e aggiorna il codice di origine per conto dell'utente.
Quando si carica inizialmente un portlet, l'inizializzazione si basa sui parametri ricavati dal descrittore di distribuzione Web (web.xml). I parametri vengono definiti nell'elemento <init-param> dell'elemento <servlet>. È possibile ottenere questi parametri utilizzando il metodo getInitParameter() dell'oggetto PortletConfig. Il portlet risultante è un portlet astratto.
Prima di utilizzare un portlet, i parametri ricavati dal descrittore di distribuzione portlet (portlet.xml) vengono caricati in un oggetto PortletApplicationSettings o PortletSettings. Questi parametri sono impostati sull'elemento <context-param> dell'elemento <concrete-portlet-app> e sull'elemento <config-param> dell'elemento <concrete-portlet>.
I parametri sull'elemento <concrete-portlet-app> si applicano a tutti i portlet dell'applicazione portlet; possono essere recuperati con il metodo PortletSettings.getApplicationSettings(). Il metodo getApplicationSettings() restituisce un oggetto PortletApplicationSettings e il metodo PortletApplicationSettings.getAttribute() viene utilizzato per recuperare i parametri. I parametri sull'elemento <concrete-portlet> si applicano ai portlet specifici; possono essere recuperati con il metodo PortletSettings.getAttribute().
La combinazione di un portlet astratto più i dati da un oggetto PortletSettings viene chiamata portlet reale.
Quando si inserisce un portlet in una pagina del portale, viene creato un oggetto PortletData. La combinazione di un portlet reale più un oggetto PortletData viene chiamata istanza del portlet reale. Gli oggetti PortletData gestiscono i dati persistenti per le istanze dei portlet reali. I valori vengono recuperati utilizzando i metodi PortletRequest.getData() e PortletData.getAttribute(), e memorizzati utilizzando i metodi PortletData.setAttribute() e PortletData.store(). I dati si riferiscono a un utente oppure a un gruppo, a seconda dell'ambito della pagina del portale.
La combinazione di un'istanza di portlet reale più un oggetto PortletSession viene chiamata istanza del portlet utente.
La seguente illustrazione mostra gli oggetti appena descritti.
![]() |
Utilizzando JSR 168 portlet API, i parametri iniziali vengono definiti in portlet.xml con l'elemento <portlet-preferences>. L'elemento <init-param> in web.xml per IBM portlet API è equivalente all'elemento <init-param> in portlet.xml per JSR 168 portlet API.
Questi parametri iniziali possono essere impostati su sola lettura, ma possono essere modificati al runtime in modalità di configurazione. I parametri di inizializzazione in sola lettura possono essere modificati unicamente da un amministratore. Se modificati durante il runtime, viene richiamata una classe validator. Anche il nome della classe validator viene impostato sull'elemento <portlet-preferences>. L'oggetto PortletPreferences rende questi parametri disponibili nel portlet attraverso i metodi RenderRequest.getPreferences(), PortletPreferences.getValue() e PortletPreferences.getValues(). L'elemento <portlet-preferences> è equivalente all'elemento <config-param> più l'oggetto PortletData in IBM portlet API.
La combinazione di un oggetto PortletPreferences e di un portlet è nota come entità portlet. Una finestra portlet viene definita come combinazione della modalità portlet (modifica, vista), dello stato della finestra portlet (normale, ingrandita, ridotta) e dei parametri di render. Una pagina di portale può contenere più di una finestra portlet per un determinato portlet, ciascuna associata a una modalità, a uno stato e a un set di parametri di render.
La seguente illustrazione mostra gli oggetti appena descritti.
![]() |
Entrambe le API per i portlet utilizzano un ciclo di vita che consiste di una fase di inizializzazione, di una fase di elaborazione delle richieste e di una fase di distruzione. La fase di elaborazione delle richieste è suddivisa in due fasi: elaborazione delle azioni e rendering del contenuto. I dettagli sulla fase di elaborazione delle richieste vengono descritti in Elaborazione delle richieste. Di seguito vengono elencati e descritti i metodi specifici richiamati in ciascuna fase.
Entrambe le API per i portlet utilizzano un'elaborazione delle richieste a due fasi. Vengono elaborate prima le azioni (o gli eventi), quindi viene richiamata la fase di rendering. In IBM portlet API, la fase azione viene richiamata attraverso il metodo actionPerformed(), mentre la fase di rendering viene richiamata dal metodo service(). In JSR 168 portlet API, le due fasi vengono richiamate attraverso i metodi processAction() e render().
Una grande differenza tra le due API consiste nel fatto che JSR portlet API utilizza oggetti richiesta e risposta differenti nelle fasi di azione e di rendering, mente IBM portlet API utilizza gli stessi oggetti nelle due fasi. Utilizzando IBM portlet API, è possibile impostare attributi sugli oggetti richiesta e risposta durante l'elaborazione degli eventi e richiamare i valori durante la fase di rendering. Utilizzando JSR portlet API, è possibile passare i valori degli attributi utilizzando l'oggetto sessione oppure i parametri di render.
Un'altra differenza consiste nel fatto che il metodo actionPerformed() di IBM portlet API utilizza il parametro ActionEvent per accedere all'oggetto PortletRequest. Il metodo processAction() di JSR 168 portlet API presenta i parametri ActionRequest e ActionResponse, che implementano le interfacce PortletRequest e PortletResponse.
A questo punto, è possibile iniziare l'Esercizio 1.3: Confronto delle differenze delle classi JavaTM.