Di seguito un esempio di richiesta di actionURL su una pagina con tre Portlet (A,B,C):
Se la richiesta dell’utente è attivata da una renderURL, il Portlet Container deve attivare la richiesta di rendering richiamando il metodo di render per tutte le Portlet nella pagina del Portale ad eccezione delle Portlet il cui contenuto è memorizzato nella cache. Le richieste di rendering possono essere eseguite in sequenza o in parallelo senza alcun ordine garantito. Il Portlet Container non deve invocare il processAction di nessuna delle Portlet nella pagina del Portale.
Se la richiesta dell’utente è attivata da una resourceURL, il Portlet Container deve invocare il metodo serveResource della Portlet corrispondente con la possibile eccezione di restituire direttamente il contenuto che ha una valida entry nella cache per la corrispondente richiesta. Il Portlet Container non deve invocare nè il processAction e nè il render di nessuna delle Portlet nella pagina del Portale.
Il Portlet Container gestisce le richieste simultanee per la stessa portlet con l’esecuzione concorrente di diversi thread che si occupano di invocare i metodi di gestione delle richieste elencati. Gli sviluppatori delle Portlet devono progettare le loro portlet in modo da gestire l’esecuzione simultanea di più thread all’interno dei metodi processAction e render, o di uno qualsiasi dei metodi opzionali processEvent o serveResource.
Le specifiche java 2.0 delle Portlet mettono a disposizione nelle API l’interfaccia javax.portlet.Portlet. Ogni Portlet deve implementare direttamente o indirettamente questa interfaccia cosicchè il Portlet Container possa gestire il suo ciclo di vita:
Inizialmente il Portlet container invoca il metodo init per inizializzare la Portlet e permetterle di processare le richieste di action e render. Successivamente reindirizza alla Portlet le richieste di action e render rispettivamente con i metodi processAction e render. In particolare nel metodo processAction la Portlet può: effettuare una redirect, cambiare la sua modalità (view, edit, help), modificare il suo stato persistente e settare i parametri di rendering. Infine il Portlet Container invoca il metodo destroy per disattivare la Portlet. Prima della disattivazione, però la Portlet deve aver finito di liberare le risorse che occupa (memoria, thread, ecc…) e assicurarsi che il suo stato persistente sia sincronizzato con lo stato della Portlet in memoria.
Nelle API è presente anche un’implementazione base astratta della Portlet: javax.portlet.GenericPortlet. Il cui comportamento è il seguente:
- Implementa il metodo processAction cercando all’interno della sottoclasse un metodo annotato con @ProcessAction ed invocandolo, altrimenti lancia una PortletException.
- Implementa il metodo render settando il titolo della Portlet ed invocando il metodo doDispatch. Quest’ultimo invoca un metodo annotato con @RenderMode ed invoca uno fra i metodi doView, doEdit, doHelp a seconda della modalità della Portlet
- Definisce il metodo processEvent, il quale cerca un metodo annotato con @ProcessEvent che coincide con il nome dell’evento generato e lo invoca.
Liferay è una piattafaroma opensource che rispetta le specifiche Java Portlet 2.0 ed è distribuita come un’applicazione web insieme ai più comuni web/application server opensource: tomcat, jboss, glassfish, ecc…
Permette di installare e disinstallare le Portlet all’interno di una pagina web con un semplice drag and drop. Ogni Portlet è deploiata come un plugin all’interno di una istanza di Liferay. Ogni plugin contiene una o più Portlet in modo da distribuire la propria applicazione in tante piccole parti che possono essere composte dinamicamente nelle pagine del portale, seguendo quindi sempre la filosofia dello sviluppo a componenti.
Non ci resta, quindi, che vedere come sviluppare una portlet integrabile dentro liferay. Ma questo lo vedremo nel successivo articolo.
