Ma ci sono anche delle differenze: le Portlet restituiscono solo una porzione della pagina web che sarà poi assemblata dal Portale; possono essere invocate attraverso degli URL generati dalle API delle Portlet e solo indirettamente attraverso il Portale; hanno una gestione delle richieste più elaborata (richieste di action, event, render, resource); sono definite in diverse “modalità” (view, edit, help); possono essere istanziate più volte all’interno di una stessa pagina; ecc…
Quali possono essere, dunque, i vantaggi di realizzare un portale rispetto ad un’applicazione classica con le Servlet? Sostanzialemnte il vantaggio è individuabile nel concetto stesso di Portlet: una porzione di una pagina che offre informazioni e/o servizi con la possibilità di personalizzarle in base agli utenti del Portale. Realizzare un Portale vuol dire creare una comunità e/o un’organizzazione di utenti, ognuno dei quali accede a specifiche informazioni e ognuno dei quali ha accesso ad alcune informazioni piuttosto che altre, quindi ad alcune Portlet piuttosto che altre. Ciò facilità la gestione e la produttività delle società o organizzazioni che intendono fornire dei servizi online. Da un lato la gestione stessa del Portale segue di pari passo la struttura della società o organizzazione. Dall’altro la produttività aumenta inquanto il Portale stesso può essere aggiornato seguendo una filosofia di sviluppo a componenti: realizzo una pagina come composizione di diversi semplici servizi, ognuno dei quali può essere facilmente aggiunto o rimosso dalle pagine.
Chi sviluppa una Portlet deve tener presente della sua natura di porzione di pagina web e che quindi ogni volta che un utente compie un’azione su una pagina web, ad esempio clicca un link o su un bottone, questa sarà diretta ad una sola Portlet. Il Portale deve reindirizzare l’azione alla Portlet in questione e successivamente mostrare l’intera pagina, il cui contenuto può essere cambiato e quindi anche quello di alcune Portlet. Ma non tutte le Portlet avranno cambiato il loro contenuto e ritorneranno pertanto sempre lo stesso risultato.
Ciò comporta che le richieste alle portlet possono essere di due tipi: action e render. Più precisamente una richiesta d’interazione con il Portale prevede due fasi (action e render) e tre tipologie di URL richiesti (actionURL, renderURL e resourceURL).
- fase di action : è la prima fase di interazione con il Portale ed è richiesta ad una sola Portlet della pagina. In questa fase la portlet può cambiare stato quindi è consigliato effettuare eventuali insert o update al database in questa fase. L’esistenza di questa fase non è obbligatoria e può essere bypassata se l’interazione dell’utente non prevede modifiche di stato o contenuti
- fase di render : è la fase successiva a quella di action ed è invocata su tutte le Portlet della pagina per effettuare il loro rendering, cioè ritornare il contenuto, compresa ovviamente quella per cui è stata effettuata la fase di action. L’ordine di invocazione delle Portlet non è predefinito e può essere random
- actionURL : utilizzato per indicare alla portlet a cui è indirizzata l’azione di compiere la sua fase di action prima del rendering delle altre Portlet
- renderURL : utilizzato per indicare alle Portlet della pagina di effettuare le loro fasi di render
- resourceURL : utilizzato per recuperare immagini, file XML, JSON o qualsiasi altro tipo di risorsa. E’ utile anche per effettuare delle richieste AJAX al server. La differenza rispetto alle altre due tipologie di URL è che la Portlet ha il pieno controllo dei dati che devono essere restituiti nella risposta all’utente
Se la richiesta dell’utente è attivata da una actionURL, il Portlet Container deve prima attivare l’azione richiesta richiamando il metodo processAction della Portlet corrispondente. Quest’ultima può generare degli eventi su cui possono essere in ascolto altre Portlet. Il Portlet Container deve attendere fino al termine della processAction e poi deve chiamare il metodo processEvent delle Portlet che sono in ascolto sugli eventi generati dal metodo processAction della Portlet che ha effettuato la fase di action. Terminati tutti i processEvent 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.
