|
È molto più bello sapere qualcosa di tutto, che tutto di
una cosa
|
|
| Home Page |
|
| Articoli |
|
| News |
|
| Forum |
|
| Classi |
|
|
|
|
|
Vantaggi dell’uso di portali JSF e JSR 168 per sviluppare applicazioni Ajax
By
Christophe Jolif
27 settembre 2007
|
 |
|
Ajax è uno degli argomenti caldi del momento, bene avviato per diventare uno standard de-facto per la prossima generazione di applicazioni Web grazie ai molti vantaggi che porta con sé, fra i quali:
- Migliore accettazione e produttività da parte degli utenti, che godono di un’esperienza simile a quella nativa del computer
- Semplicità di distribuzione, con disponibilità immediata degli aggiornamenti da parte di tutti gli utenti
- Aderenza agli standard e dipendenza esclusiva da tecnologie ampiamente diffuse
- Importante comunità di sviluppatori con progetti open-source molto attivi
- Semplici miglioramenti incrementali alle applicazioni Web esistenti
- Un’organizzazione di successo, la OpenAjax alliance, sostenuta dai grandi protagonisti del mercato per diffondere le competenze su Ajax e incoraggiare l’interoperabilità
Per gli sviluppatori, però, salire sul carro Ajax non significa affatto poter contare su un percorso confortevole, ma rappresenta anzi una scelta molto impegnativa. Per esempio, l’ecosistema di sviluppo non è così ricco e produttivo come la sua controparte standalone e per applicazioni su larga scala la comunicazione asincrona con il server può diventare rapidamente difficile da progettare, debuggare e mantenere.
La piattaforma Java
Per gli sviluppatori che lavorano in area Java, due tecnologie lato server possono aiutare a superare alcune delle asperità che lo sviluppo di applicazioni Ajax presenta:
- JavaServer Faces (JSF) è uno standard Java [1] derivato dall’esperienza Struts. Esso permette di accelerare lo sviluppo di applicazioni Web grazie a un sistema di strumenti fatto di ambienti di sviluppo integrati come Oracle Jdeveloper, IBM/Rational Application Developer e Sun Studio Creator, oltre che di server Web “JSF-ready” come IBM Websphere Application Server, BEA Weblogic e Oracle Application Server.
- I portali, come quelli aderenti allo standard JSR 168, introducono altri benefici per quanto riguarda l’aggregazione dei contenuti, il single sign-on e la personalizzazione della visualizzazione con la persistenza, per offrire all’utente un’esperienza personalizzata.
Questo articolo propone una breve panoramica su come sia possibile usare i portali basati su JSF ed JSR 168 per la distribuzione di applicazioni Ajax. Vedremo prima come integrare JSF in portali JSR 168 e quindi come estendere queste componenti JSF per introdurre comportamenti Ajax all'interno dei portali.
Christophe Jolif, è Lead Software Architect, ILOG JViews Visualization Products.
Download di questo articolo in pdf.
|
|
|
Integrazione di componenti base JSF in un portale
|
top
|
Da un lato, la specifica JSF supporta lo use-case della distribuzione di portlet mediante un’API astratta, che permette di andare oltre le servlet, ma la cui implementazione di riferimento [3] non può essere eseguita in quanto tale in un ambiente portlet JSF 168. È allora necessaria l’implementazione bridge di riferimento delle portlet JSF [4], o il bridge corrispondente alla propria particolare implementazione JSF, insieme all’implementazione di riferimento JSF di default.
Anche se una portlet JSF è pacchettizzata in modo molto simile a una normale applicazione JSF, esistono alcune differenze.
I passi aggiuntivi per creare una portlet con la tecnologia JSF sono i seguenti:
- Copiare il bridge portlet jsf-portlet.jarnella directory WEB-INF/libdell’applicazione JSF.
- Aggiungere un nuovo deployment descriptor di portlet, portlet.xml, nella directory WEB-INF dell’applicazione.
Quello seguente è un tipico deployment descriptor portlet.xml, in cui il parametro INIT_VIEW è stato sostituito per puntare ad una pagina JSP ad-hoc.
<portlet-app […]>
<portlet>
<description>JSF Portlet</description>
<portlet-name>jsfPortlet </portlet-name>
<display-name>JSF Portlet</display-name>
<portlet-class>com.sun.faces.portlet.FacesPortlet</portlet-class>
<init-param>
<description>Portlet init view page</description>
<name>com.sun.faces.portlet.INIT_VIEW</name>
<value>/index.jsp</value>
</init-param>
<supports>
<mime-type>text/html</mime-type>
<portlet-mode>VIEW</portlet-mode>
</supports>
<portlet-info>
<title>JSF Portlet</title>
<short-title>jsfPortlet</short-title>
</portlet-info>
</portlet>
</portlet-app>
3. Evitare ogni elemento <html>, <head>, <body> e qualunque altro tag proibito dalle specifiche JSR 168 [2] nelle pagine JSF/JSP della portlet. Le pagine risultanti verranno infatti successivamente incluse nella pagina HTML del portale.
4. All’interno dei tag <p:portletPage>, a loro volta contenuti nei tag <f:view>, utilizzare solo tag JSF, per garantire ID unici alle diverse portlet. Il visualizzatore del tag <p:portletPage> impone che tutte le sue sottocomponenti usino ID univoci per le diverse portlet dell’intera pagina del portale. Per esempio:
<f:view>
<p:portletPage>
<h:form>
<h:anyComponent/>
</h:form>
</p:portletPage>
</f:view>
5. Distribuire il WAR della portlet risultante come specificato per l'ambiente di portale in uso.
Mediante questi cinque passi è possibile distribuire il componente JSF in un portale JSR 168. Quando si voglia andare oltre l’implementazione JSF di default per componenti con comportamento Ajax [10] sarà necessario procedere a passi ulteriori.
|
|
Integrazione di un componente JSF Ajax in un portale
|
top
|
Vedremo ora brevemente come i componenti JSF sono solitamente sviluppati per gestire le richieste asincrone necessarie per realizzare un comportamento Ajax. Per maggiore chiarezza, la spiegazione sarà basata sul campo di input con auto suggerimento.
Nell’esempio di codice seguente, il componente autoSuggest ha sia un attributo value, usato per la visualizzazione, che uno suggestMethod. Esso referenzia un bean gestito dal server, che produce tutti i testi dei suggerimenti per la parola chiave inserita:
Pagina JSP di esempio:
<foo:autoSuggest value=”initial value”
suggestMethod=”#{myServerBean.getSuggestion}”/>
Bean gestito dal server di esempio:
public class MyServerBean {
public String[] getSuggestion(String prefix) {
// query the response somewhere and returns it
return new String[] {};
}
}
Oltre al tag HTML <input>, questo componente JSF interpreta il codice JavaScript per inviare richieste asincrone al server quando l’utente inserisce dei caratteri, mediante chiamate ad XmlHttpRequest. Quindi visualizza la risposta del server nel browser.
La richiesta Ajax di suggerimenti al server contiene un parametro aggiuntivo, &autosuggest=’value’. Questa richiesta è elaborata da una istanza di PhaseListener JSF 1.2, registrata nel ciclo di vita JSF del server mediante un file faces-config.xml. Essa restituirà il suggerimento come JSON o come dati XML, come mostrato in [5]. La stessa richiesta Ajax contiene anche il riferimento al metodo puntato dal tag <foo:autoSuggest>.
Per esempio, se un utente vuole avere un suggerimento per la parola chiave “start”, la XmlHttpRequestrichiama il seguente PhaseListener:
public class AutoSuggestRequestHandler implements PhaseListener {
private class Class[] PARAMS = new Class[] { String.class };
public void afterPhase(PhaseEvent event) {
FacesContext ctx = event.getFacesContext();
HttpServletRequest request = (HttpServletResponse)
ctx.getExternalContext().getRequest();
Object autosuggest = request.getParameter(“autosuggest”);
if (autosuggest != null) {
try {
// get the method the user has specified for auto-suggestion
// the reference to the method is available in the “method”
// parameter
MethodExpression mx =
ctx.getApplication().getExpressionFactory().
createMethodExpression(ctx.getELContext(),
request.getParameter(“method”),
String.class, PARAMS);
// get the auto suggestion result from the method
Object[] args = new Object[] { autosuggest };
Object[] result = mx.invoke(ctx.getELContext(), args);
// send the suggestions to the client using JSON utilities
JSONUtil.write(response.getHttpResponse().getOutputStream(),
result);
} catch (Exception e) {
// log error
} finally {
// cut the lifecycle to avoid rendering components
ctx.responseComplete();
}
}
}
public void beforePhase(PhaseEvent event) {}
public PhaseId getPhaseId() {
return PhaseId.RESTORE_VIEW;
}
}
Questo approccio deve ancora essere migliorato per gestire correttamente il contesto della portlet.
I valori restituiti dall’ExternalContext sono esplicitamente convertiti in oggetti servlet. Questo approccio non funziona nel contesto corrente della portlet. Perché i parametri siano ricevuti correttamente sì può usare il codice seguente:
ctx.getExternalContext().getParameterMap().get(“autosuggest”)
Il bridge portlet elabora le richieste Ajax come richieste JSF, le inoltra alle diverse portlet e aggrega tutte le risposte in una risposta singola. Il componente JavaScript all’interno del browser riceverà come dati JSON non solo la risposta del PhaseListener , ma l’intero set di dati di tutte le portlet, che è molto più difficile da interpretare.
Per evitarlo, la gestione delle richieste Ajax di auto suggerimento non è realizzata dal PhaseListener, ma da una servlet esterna.
Quindi la richiesta non sarà intercettata dal bridge portlet e le risposte del server saranno inviate come dati JSON parziali, come ci si aspetta.
Quella che segue è una servlet di esempio che può sostituire il PhaseListenerin un contesto di portale:
public class AutoSuggestServlet extends HttpServlet {
protected void doGet(HttpServletRequest req,
HttpServletResponse resp)
throws ServletException, java.io.IOException {
FacesContext ctx =
ServletFacesUtil.createFacesContext(req, resp);
Map params = ctx.getExternalContext().getParameterMap();
Object autosuggest = params.get(“autosuggest”);
if (autosuggest != null) {
try {
MethodExpression mx =
ctx.getApplication().getExpressionFactory().
createMethodExpression(ctx.getELContext(),
params.get(“method”),
String.class, PARAMS);
Object[] args = new Object[] { autosuggest };
Object[] result = mx.invoke(ctx.getELContext(), args);
JSONUtil.write(resp.getOutputStream(),
result);
} catch (Exception e) {
// log error
} finally {
// release our temporary FacesContext
ctx.release();
}
}
}
}
Il codice è molto simile, ma invece di ottenere il FaceContext dall’API JSF, utilizziamo ServletFacesUtil.createFacesContext()per ottenere la nostra istanza:
- Non usiamo FacesContext.getCurrentInstance() in quanto l’istanza sarebbe null, poiché non siamo all’interno del contesto FacesServlet.
- Non usiamo direttamente FacesContextFactory perché essa si aspetta oggetti portlet, come PortletContext o Portletsession, invece di oggetti servlet come ServletContexto HttpSession, a causa del bridge portlet. Ricordiamo che stiamo usando una servlet in sostituzione di un PhaseListener. Prima di chiamare FacesContextFactory occorre recuperare o costruire degli oggetti Portlet.
Questo approccio basato su ServletFacesUtil.createFacesContext() funziona quando il gestore del componente memorizza gli oggetti context e session utilizzando APPLICATION_SCOPE. Questi oggetti possono quindi essere recuperati dalla servlet e gli oggetti requeste responsepossono essere costruiti grazie alla delega sui corrispondenti oggetti servlet.
Un’altra insidia comune che si incontra nella codifica di componenti JSF Ajax per le portlet è quella di avere due variabili JavaScript distinte, in portlet diverse, con lo stesso nome. La soluzione è di anteporre al nome delle variabili lo spazio dei nomi della portlet:
- Usare UIComponent.getClientId() come nomi di variabili, in quanto i componenti sono racchiusi in un tag <p:portletPage>
- Oppure applicare il metodo ExternalContext.encodeNamespace()dell’API JSF.
|
|
Conclusioni e Riferimenti
|
top
|
Tutte le soluzioni esposte in questo articolo sono state applicate con successo nello sviluppo di applicazioni con componenti di visualizzazione ILOG Jviews. [6]
In conclusione, è necessario fare molta attenzione nella progettazione dei componenti JSF con comportamento Ajax in portali JSR 168. Le specifiche JSR 168 e i bridge portlet attuali non sono progettati secondo questo use case. Tuttavia nuove JSR, come la specifica Portlet 2 [7] e la specifica del bridge portlet per JSF [8] si propongono di affrontare gli attuali problemi dei componenti JSF Ajax nei portali. La OpenAjax Alliance intende affiancare questi impegni con la creazione di una task force di Server Integration [9] per aiutare a integrare i componenti Ajax all’interno di framework lato server come i JSF.
Riferimenti:
[1] JSF 1.2 Specification -
[2] Portlet Specification -
[3] JSF Reference Implementation -
[4] JSF Portlet Bridge Reference Implementation -
[5] Using PhaseListener Approach for Java Server Faces Technology with AJAX
[6] ILOG JViews Products –
[7] Portlet 2.0 Specification -
[8] Portlet Bridge Specification for JSF -
[9] OpenAjax Alliance Server Integration Task Force –
[10] Ajax: A New Approach to Web Application –
|
|
|
Eccetto dove diversamente specificato, i contenuti di questo sito sono rilasciati sotto licenza Creative Commons
|
|
|
Documentazione
>
WP - JViews Ajax JSF Portlets2.pdf
