Guest

Introduzione agli Hooks: primo episodio

Antonio Musarra — Mon, 13 May 2013 19:24:38 GMT

L’insediamento dell’Open Source nel mondo del cosiddetto Enterprise prosegue in modo inesorabile ma alcune organizzazioni sono ancora restie all’adozione di software Open Source e hanno delle giustificate ragioni. La manutenzione delle personalizzazioni (da riesaminare per ogni nuova release) è uno dei motivi che giustifica questa diffidenza nei confronti dei software Open Source.

Ipotizziamo per un attimo di poter “agganciare tramite un arpione” le personalizzazioni implementate senza toccare il core del software, direi che sarebbe un’operazione fantastica, bene, Liferay ha introdotto di recente un nuovo tipo di plugin che prende per l’appunto il nome di Liferay Hooks (Liferay Inc, 2012). Questa nuova via di estensione fornisce un livello di separazione tra le vostre personalizzazioni e il core di Liferay, diminuendo drasticamente la complessità di personalizzazione, introducendo inoltre una notevole libertà di movimento senza la preoccupazione di dover tener tracciata del codice sorgente a ogni release del core di Liferay.

Restando nell’orto delle personalizzazioni, un'altra strada “più larga” da percorrere in scenari complessi, dove gli altri tipi di plugin non arrivano, si chiama Liferay Ext (Liferay Inc, 2012). La trattazione di questa “bestia” non è però oggetto di quest’articolo, magari di un futuro.

A questo punto direi che sia venuto il momento di scrutare più da vicino gli hooks e per quali scopi possano essere utilizzati, per poi immediatamente saltare alla realizzazione pratica di un hook per personalizzare Liferay. La versione di riferimento di Liferay è la 6.1 edizione Community Edition.

1. Obiettivo

L’articolo intende comunicare le informazioni base che riguardano gli hooks favorendo l’aspetto reale, in altre parole, far capire a cosa servono tramite l’esposizione e realizzazione di un caso di studio quanto più possibile vicino al reale. Sarà quindi presentato un caso d’integrazione che farà uso degli hooks, toccando i vari aspetti di personalizzazione. L’articolo sarà suddiviso in più episodi per evitare una “sbrodolata” d’informazione e rendere più efficace l’assimilazione di quanto esposto.

2. Gli Hook in breve

Che cosa sono gli hooks? Il nome è più che azzeccato, in effetti, sono parti di codice “agganciate” a Liferay che in genere sovrascrivono alcune delle funzioni del portale.

Tramite questo tipo di plugin è possibile per gli sviluppatori sovrascrivere parti del core di Liferay con le proprie implementazioni, mantenendo una netta separazione tra il codice personalizzato e il core di Liferay.

Qualcuno potrebbe giustamente obiettare con una domanda del tipo: perché non utilizzare l’Ext plugin? Poiché l’Ext plugin fornisce l’accesso completo alle parti interne del core di Liferay, il codice personalizzato diventerebbe strettamente accoppiato a particolari implementazioni di funzioni interne che spesso potrebbero cambiare da una release a un’altra, basterebbe quindi un semplice cambio di firma di un metodo per causare un gran mal di testa a colui il quale deve riesaminare il codice personalizzato.

Così come portlet, theme, layout e così via, anche gli hooks sono hot-deployable[1], quindi aggiungere e rimuovere è un’operazione semplice. La possibilità di suddividere funzionalità complesse in più hook, sviluppati da persone diverse, rende dinamico l’ambiente di sviluppo e inoltre l’uso del set di API pubbliche di Liferay per la scrittura dell’hook rende semplice la revisione del codice personalizzato grazie alla corretta segnalazione dei deprecati. Gli hooks sono stati progettati per superare molte delle limitazioni dell’Ext e i punti di estensione disponibili crescono a ogni release di Liferay anche grazie ai feedback ricevuti da parte degli utenti.

Come fare a scegliere lo strumento di estensione più adeguato? Utilizzare gli hook dove possibile. Sono più semplici da implementare, installare, rimuovere e manutenere. Ricorre all’uso dell’Ext (Liferay Inc, 2012) solo nel caso in cui ciò che è richiesto non può essere soddisfatto tramite hook.

Nel prossimo paragrafo vedremo ciò che è possibile personalizzare tramite hook.

3. Cos’è possibile personalizzare tramite Hook

La strada consigliata per la personalizzazione delle funzioni base di Liferay, sono gli hooks (Liferay Inc, 2012). Tramite gli hooks è possibile coprire un ampio spettro di necessità e dovrebbero essere utilizzati al posto dell’Ext, quando possibile. Gli hooks sono stati progettati per personalizzare fondamentalmente cinque caratteristiche principali del portale:

· Portal properties

· Language properties

· Web Resources

· Performing custom actions

· Services

Come per le portlet, layout e temi, anche gli hooks sono creati e gestiti utilizzando il Plugin SDK[2].

Nella trattazione degli hooks e in particolare del caso di studio illustrato in seguito, vedremo i seguenti aspetti che saranno suddivisi in episodi diversi:

· Portal properties

· Performing custom action

· Web Resources

· Servlet filter hook

4. Creazione di un hook

Gli hooks risiedono all’interno della directory hooks del Plugin SDK. Esistono vari metodi che potete utilizzare per creare i vostri hooks alcuni dei quali sono:

· Developer Studio

· Comando create del Plugin SDK

· Apache Maven

Per maggiori approfondimenti sulla creazione degli hooks fare riferimento a (Liferay Inc, 2012) per i primi due punti mentre per l’ultimo consiglio la consultazione di (Koivisto, Getting started with Liferay Maven SDK, 2012), (Koivisto, Developing Liferay Plugins with Maven, 2012) (Musarra, 2012)

5. Caso d’integrazione tramite Hook

Gli hooks possono essere molto efficaci nelle soluzioni d’integrazione tra Liferay e altri sistemi esterni. In questo paragrafo vedremo come poter sfruttare gli hooks come punto “d’intermediazione” tra Liferay e un sistema di CRM.

Figura 1 Macro architettura d’integrazione tra Liferay e CRM.

La macro architettura d’integrazione mostrata in Figura 1 illustra chiaramente quali sono gli elementi interessati dal caso d’integrazione proposto. Volutamente sono stati evidenziati in nero gli elementi che riguardano il CRM per porre l’accento sul fatto che devono essere considerati vere e proprie scatole nere e concentrare l’attenzione verso gli hooks.

5.1 Ipotesi d’integrazione

Alcuni degli utenti memorizzati su Liferay (che accedono al portale) sono clienti dell’ipotetica azienda Dontesta Corporation Ltd (che vende prodotti per l’equitazione) e le schede commerciali dei clienti sono registrate sul sistema interno di CRM. Non necessariamente gli utenti definiti su Liferay sono clienti dell’azienda e di conseguenza gestiti sul CRM. L’esigenza dell’azienda è di dare la possibilità d’accesso diretto alle schede dei contatti e aziende direttamente dal portale Liferay.

Figura 2 Esempio di UI per accesso alle schede CRM del contatto e azienda.

Il mockup[3] illustrato in Figura 1 è un buon esempio di come l’interfaccia utente su Liferay si dovrebbe presentare agli utenti per consentire loro l’accesso alle schede del CRM. Con un po’ d’occhio è possibile notare come il mockup di Figura 1 è spudoratamente vicinissimo alla lista Utenti e Organizzazioni accessibile da pannello di controllo di Liferay.

Garantire l’accesso alle schede (contatto e azienda) si traduce nella necessità di poter memorizzare alcuni dati presenti sul CRM come attributi aggiuntivi dell’utente Liferay. I dati da prelevare dal sistema di CRM sono:

· L’identificativo del contatto;

· L’identificativo dell'azienda cui il contatto appartiene.

I dati sopra menzionati sono indispensabili per comunicare al CRM quale contatto o azienda s’intende visualizzare. L’accesso ai dati del CRM da parte di Liferay avviene tramite la scatola nera CRM Integration API indicata nel diagramma di Figura 1.

5.2 Dove memorizzare i dati del CRM

E’ plausibile pensare ai dati provenienti dal CRM come estensione del modello utente di Liferay, d’altronde questi dati arricchiscono l’utente di altre informazioni. Liferay mette a nostra disposizione uno strumento davvero potente che consente facilmente di realizzare quanto pensato e illustrato in Figura 3.

Figura 3 Modello Utente Liferay esteso.

Sicuramente il nome di campi personalizzati (o custom fields) non suona del tutto nuovo, bene, questo è lo strumento con il quale definire sul modello utente due nuovi attributi (topic Extended CRM Attribute di Figura 3) specificandone anche il tipo:

· ContactId: attributo di tipo stringa il cui valore è l’identificativo (UUID[4]) del contatto sul sistema di CRM;

· AccountId: attributo di tipo stringa il cui valore è l’identificativo (UUID) dell’azienda cui il contatto appartiene;

I due nuovi attributi creati per il modello utente di Liferay conterranno quindi i valori necessari per recuperare in seguito le informazioni di dettaglio del contatto e azienda. In Figura 4 è mostrato il dettaglio di un utente e in particolare sono evidenziati i valori dei due attributi ContactId e AccountId.

Figura 4 Dettaglio dell’utente con particole vista degli attributi CRM.

5.3 Quando e come memorizzare i dati del CRM

Direi che siamo arrivati al punto interessante del caso d’integrazione. E’ stato definito l’obiettivo, i dati del CRM cui accedere e quale strumento utilizzare per memorizzare questi ultimi, non resta che altro che scoprire quando accedere al CRM per recuperare i dati di nostro interesse e come memorizzarli su i due nuovi attributi definiti in precedenza.

Il portale Liferay supporta un gran numero di eventi che accadono in certe situazioni e tramite hook è possibile quindi eseguire una o più azioni personalizzate (performing custom actions) al verificarsi di un determinato evento. Le azioni che sono eseguite per ognuno degli eventi supportati dal portale, sono definite nel file di configurazione portal.properties. Attraverso l’hook dovremmo quindi:

· Estendere il file di configurazione portal.properties;

· Creare la nuova azione da eseguire per un determinato evento.

Il tipo di evento che calza a pennello con il nostro caso d’integrazione è di user login e in particolare l’evento login post action. Quest’evento è idoneo per eseguire l’azione di recupero e memorizzazione dei dati ContactId e AccountId.

Figura 5 Processo di login sul portale Liferay.

Il processo mostrato in Figura 5 rende più chiaro il processo di login. Il diagramma mostra solamente la parte di processo di nostro interesse. L’evento di login post action è scatenato nel momento in cui è stato accertato che l’utente abbia inserito le corrette credenziali, a quel punto tramite l’Event Processor sono eseguite tutte le azioni definite dalla proprietà login.events.post. Il file portal.properties del nostro hook, dovrebbe contenere la configurazione mostrata al Listato 1.

## Portal Events

# Login event

Listato 1 Definizione dell’azione da eseguire all’evento di login post action.

L’azione da eseguire nel momento in cui avviene l’evento, è una classe che estende la classe astratta com.liferay.portal.kernel.events.Action di cui occorre implementare il metodo com.liferay.portal.kernel.events.Action#run(). Ricordo che non siamo limitati a specificare una sola classe.

All’interno del metodo run() andrà inserito il codice necessario per eseguire i seguenti task:

· Recupero dell’utente che ha eseguito con successo il login;

· Prendere contatto con il CRM presentandosi con le credenziali dell’utente che ha appena eseguito il login;

· Recupero i dati d’interesse dal CRM, che ricordo essere, il ContactId e l’AccountId;

· Recupero l’Expando Bridge[5] sul modello dell’utente;

· Tramite l’ausilio dell’Expando Bridge memorizzo i dati ricevuti dal CRM nei rispettivi attributi estesi definiti in precedenza (vedi Figura 3).

package it.dontesta.liferay.portal.events;

/**

public class LoginPostAction extends Action {

* (non-Javadoc)

* @see com.liferay.portal.kernel.events.Action#run(javax.servlet.http.

* HttpServletRequest, javax.servlet.http.HttpServletResponse)

@Override

public void run(HttpServletRequest request, HttpServletResponse response)

throws ActionException {

}

Listato 2 Classe che implementa l’azione da eseguire sull’evento login post action.

I dati così ottenuti e memorizzati sui campi personalizzati saranno utilizzati in seguito per accedere alle schede di dettaglio del CRM (Contatto e Azienda). In Figura 6 un piccolo assaggio.

Figura 6 Scheda di dettaglio Azienda aperta da Liferay.

6. Conclusioni

Questo primo episodio è stato molto stringato sulla parte introduttiva degli hooks cercando comunque di sintetizzare al meglio gli aspetti più importanti per poi focalizzare l’attenzione su un caso di studio abbastanza vicino al reale. In questa prima parte, con l’aiuto del caso di studio, è stata affrontata la personalizzazione di Liferay tramite hooks, concentrandosi su, Portal properties e Performing custom action.

Nei prossimi episodi vedremo i rimanenti aspetti (Web Resources e Servlet filter hook) ultimando il caso di studio. A conclusione di tutti gli episodi ci sarà anche il regalo finale, il repository contenente i sorgenti del progetto oggetto di studio.

Bibliografia

Koivisto, M. (2012, Mar 3). Developing Liferay Plugins with Maven. Tratto da SlideShare: http://www.slideshare.net/koivimik/developing-liferay-plugins-with-maven

Koivisto, M. (2012, Feb 1). Getting started with Liferay Maven SDK. Tratto da Liferay Blog: http://www.liferay.com/it/web/mika.koivisto/blog/-/blogs/getting-started-with-liferay-maven-sdk

Liferay Inc. (2012). Creating a Hook. Tratto da Liferay Portal 6.1 - Development Guide: http://www.liferay.com/it/documentation/liferay-portal/6.1/development/-/ai/creating-a-ho-4

Liferay Inc. (2012). Ext plugins. Tratto da Liferay Portal 6.1 - Development Guide: http://www.liferay.com/it/documentation/liferay-portal/6.1/development/-/ai/ext-plugi-4

Liferay Inc. (2012). Hooks. Tratto da Liferay Portal 6.1 - Development Guide: http://www.liferay.com/it/documentation/liferay-portal/6.1/development/-/ai/hoo-4

Musarra, A. (2012, Oct 18). Creare progetti Liferay tramite il plugin m2eclipse (Maven for Eclipse). Tratto da Antonio Musarra's Blog: http://musarra.wordpress.com/2012/10/18/creare-progetti-liferay-tramite-il-plugin-m2eclipse-maven-for-eclipse/

[1] Il processo d’installazione o aggiornamento di componenti a un server in esecuzione senza arrestare e riavviare il server stesso.

[2] E’ un ambiente di sviluppo che aiuta nello sviluppo di tutti i tipi di plugin di Liferay basato sul Apache Ant, di recente è stata introdotta anche la possibilità di realizzare plugin tramite Apache Maven.

[3] Per mockup si intende comunemente la riproduzione di un oggetto originale ad uso didattico, dimostrativo, scenografico o di comunicazione visiva

[4] L'identificativo univoco universale (universally unique identifier o UUID) è un identificativo standard usato nelle infrastrutture software, standardizzato dalla Open Software Foundation (OSF) come parte di un ambiente distribuito di computazione.

[5] E’ l’interfaccia d’accesso ai custom fields di un determinato model.

Query in esecuzione in Postgresql

Simone Celli Marchi — Mon, 29 Apr 2013 13:15:47 GMT

Al fine di poter migliorare le performance del vostro database Postgresql può essere utile conoscere quali query sono in esecuzione in un dato istante.

Senza andare ad abilitare il logging delle query lente (configurazione che è cambiata anche da versione a versione) si può semplicemente interrogare la tabella pg_stat_activity.

postgres=# SELECT datname,procpid,current_query FROM pg_stat_activity;

datname | procpid | current_query

---------------+---------+---------------

dbtest1 | 3453 | <IDLE>

dbtest2 | 25675 | SELECT * FROM test where id=100;

dbtest1 | 34533 | <IDLE>

(3 rows)

La tabella contiene altre informazioni utili come l'orario di start della query, l'ip del client da cui è stata eseguita e il nome dell'utente.

In questo modo è possibile anche avere la lista delle query che sono in esecuzione ad esempio da più di 3 secondi:

select now()-query_start tempo from pg_stat_activity where now()-query_start > '3 seconds' and current_query <> '<IDLE>';

IPC client-side in Liferay.

marcello marangio — Thu, 25 Apr 2013 15:17:50 GMT

Ciao a tutti.

La specifica JSR 286 ha indrodotto 2 modalità per lo scambio di informazioni tra portlet, noto come Inter-Portlet-Communication: uno basato sullo scambio di parametri (shared render parameters) e un modello ad eventi.

Il modello ad eventi è quello più interessante.

In breve, una portlet viene configurata per inviare un evento e una o più portlet vengono configurate per ricevere e consumare l'evento; la configurazione viene fatta nel file portlet.xml e un evento è un qualunque oggetto che sia serializable.

Supponiamo di avere una portlet che visualizza categorie ad albero nel modo classico: cliccando su una categoria appare il <div> che contiene le sotto categorie (stile portlet "Categories Navigation") e supponiamo di avere una portlet che visualizza prodotti, filtrando la lettura dalla base dati tramite la categoria cliccata sull'altra (stile asset publisher).

Nel file portlet.xml, portlet che pubblica l’evento

<supported-publishing-event>
<name> catSelected </name>
</supported-publishing-event>

pe la portlet che processa l’evento

<supported-processing-event>
<name> catSelected </name>
</supported-processing-event>

Ogni portlet che riceve l'evento, implementa il metodo

@ProcessingEvent(name = “catSelected”)
public void processoCatSelected(EventRequest request, EventResponse response)
throws IOException, PortletException {
Event event = request.getEvent();
   String catId = (String) event.getValue();
List <Prodotti> prodotti = readProdottiFromDb(catId);
request.getPortletSession().setAttribute(“prodotti”, prodotti);

L'evento viene consumato nel metodo e quindi è possibile, ad esempio, memorizzarlo nella portletSession per utilizzarlo successivamente in una pagina jsp. L'annotation serve per discriminare tra i metodi processAction che processano eventi differenti.

La portlet che invia l'evento, lo fa con l'istruzione seguente, posta in un metodo processAction

response.setEvent(“catSelected”, "123");

Viene quindi scambiato l'evento "selezionata categoria 123"

Tramite il "giro di giostra" descritto l'evento viene scambiato tra le portlet a livello server e questo implica che la pagina debba essere ricaricata interamente e che quindi dobbiamo memorizzare in qualche modo lo stato di visualizzazione delle portlet per poter ripresentare all'utente la schermata esattamente come l'ha lasciata: nel nostro caso devo ricordare quale è la categoria cliccata per poter mostrare l'albero delle categorie in modo corretto. Per portlet molto complesse questo può essere fastidioso.

Se solo si potesse utilizzare ajax...

Effettivamente possiamo fare la stessa cosa utilizzando una funzionalita di IPC messa a disposizione da LR 6.x nota come IPC client-side.

Si tratta delle funzioni javascript Liferay.fire e Liferay.on, utilizzate rispettivamente per inviare e ricevere un evento in due portlet instanziate nella stessa pagina.

In Liferay 5.x si chiamavano Liferay.trigger e Liferay.bind; sono identiche alle rispettive attuali ma hanno cambiato nome per motivi a me oscuri.

La cosa interessante è che il tutto viene fatto a livello javascript senza dover configurare nulla nei files xml delle mie portlet e tutto il giro viene generato e consumato sulla pagina tra qualunque portlet.

Per inviare un evento:

...

jQuery(function () {
    jQuery('a.categoria_item').click(
       function(event) {
           var catId = jQuery(this).next().val();
           Liferay.fire('catSelected', {categoryId: catId});            return false;
         }
       )
     }
  );

...
<a href="#" class="categoria_item">mia categoria</a>
<input type="hidden" name="catId" value="123">

In questo esempio al click sul link viene inviato un evento "catSelected" che consiste in un JSON, perfetto in questo caso.

Nella portlet che processa l'evento:

<script type="text/javascript">
Liferay.on(
   'catSelected',
   function(event) {
  var catId = event.categoryId;
  jQuery('#prodottiWrapper').html('');
     jQuery.ajax({
         type: 'POST',
         url: '<%=setCatAction%>',
         data:"catId="+catId,
         success: function(data){
             jQuery('#prodottiWrapper').html(data);
         }
       });
    return false;
   }
 );
</script>

In sostanza l'elaborazione dell'evento consiste nella chiamata ajax ad un action della mia portlet che legge dalla base dati i prodotti che appartengono alla categoria selezionata, mostrati nel <div id="prodottiWrapper"></div>.

Il risultato è che la user experience è molto più fluida, tutte le portlet che stanno intorno ignorano tutto questo dialogo e continuano a vivere felicemente nell'ignoranza, genero meno traffico di rete e infine non mi pongo il problema di memorizzare quale categoria è stata cliccata perchè il mio albero di categorie non viene ricaricato.

Hope it helps!

Marcello

Passare parametri tra due portlet

marcello marangio — Wed, 17 Apr 2013 22:05:00 GMT

Ciao a tutti.

Vorrei condividere al volo questa cosa in cui mi sono imbattuto poco fa.

Solitamente passiamo parametri a pagine diverse della stessa portlet utilizzando una renderURL e invochiamo una action di una portlet tramite la actionURL.

Ma se volessimo passare parametri da una portlet ad una pagina di un'altra? o se volessimo invocare una action di una portlet da un'altra portlet?

Lo scenario è il seguente.

Da una pagina con una portlet X voglio richiamare e visualizzare un'altra portlet Y che sta su un'altra pagina "abc".

per fare questo si usa la taglib liferay-portlet.

Nella jsp di partenza di X:

<liferay-portlet:renderURL plid="<%=destPagePlid %>"  portletName="<%=destPortletId%>" var="myVar">

<liferay-portlet:param name="myParam" value="12345" />

</liferay-portlet:renderURL>

<a href="<%=myVar%>"> clicca</a>

dove destPagePlid è la chiave primaria della pagina di destinazione, che si riesce a ritrovare con una routine di questo tipo:

long pagePlid =0;

List <Layout> pagine = LayoutLocalServiceUtil.getLayouts(themeDisplay.getScopeGroupId(), false );

for(Layout pagina : pagine){

 String pagename =pagina.getName(themeDisplay.getLocale()); 

 if(pagename.equals("abc")){

  pagePlid=pagina.getPlid();

break;

 }

}

mentre destPortletId è il portletid della portlet di destinazione, nel classico formato nomeportlet_WAR_nomewebapp

in questo modo cliccando sul link "clicca" della pagina della portlet X invoco la URL della pagina "abc", passando anche un parametro alla portlet Y instanziata in quella pagina.

In modo del tutto analogo, si può richiamare una action se invece dell'renderURL usiamo la actionURL.

Spero possa essere utile.

Ciao a tutti

Marcello

Introduzione a Liferay Message Bus

Jader Jed Francia — Fri, 12 Apr 2013 06:25:58 GMT

Era da tanto che volevo scrivere un post sul Message Bus ma il tempo per farlo "bene" non

lo riuscivo mai a trovare!

Poi un giorno Antonio Musarra ne ha scritto uno perfetto, e allora mi sono detto: "Beh, non ho più bisogno di scriverlo io, posso linkare direttamente il suo! :D"

Allora, a beneficio di tutti, ecco l'ottimo post di Antonio riguardante l'introduzione a Liferay Message Bus!

Ne approfitto anche per segnalare che Antonio scriverà per noi qualche guest post nei prossimi giorni. Così come ha già fatto Marcello Marangio, altre grandissimo dello sviluppo su Liferay e di Java in generale! :)

Oltre ad esserne fieri, ringraziamo pubblicamente entrambi per la "fattiva" collaborazione!

È bello che ci siano ancora persone a cui piace condividere la conoscenza, come tutti noi, del resto, che scriviamo e commentiamo questo blog! ;D

A presto! :)

Liferay ed utilizzo "multiplo" di categorie

Marco Napolitano — Fri, 15 Mar 2013 11:41:04 GMT

Lavorare con le proprie entità custom integrate alle categorie di Liferay è, tutto sommato, abbastanza semplice ed indolore. Tuttavia mi sono trovato recentemente a dover affrontare un problema spinoso ma, fortunamente, abbastanza inconsueto.

La situazione è la seguente:

ho definito 2 mie entità custom, che chiameremo EntitaA ed EntitaB;
ho definito i relativi AssetRender in modo da potermi integrare con le categorie;
ho creato un vocabolario ed associato ad entrambe le entità custom.

All'interno della pagina JSP (per esigenze che non sto ad approfondire) ho dovuto inserire 2 distinti form HTML, uno per EntitaA e l'altro EntitaB; in entrambi ho utilizzato la taglib di Alloy per la gestione delle categorie, ossia:

<aui:input name="categories" type="assetCategories" />

Il problema è insito nel funzionamento interno di tale taglib, che si appoggia infatti sull'altra taglib di Liferay: <liferay-ui:asset-categories-selector />. Questa taglib infatti crea un campo di testo nascosto per ogni vocabolario e gli assegna, sia come name che come id, la stringa: assetCategoryIds_<vocabularyId>.

La valorizzazione del campo nascosto è demandata al codice di Alloy della taglib; il problema è proprio qui perchè i form HTML sono sì separati ma il mio vocabolario è associato ad entrambe le entità custom e quindi nella pagina ci sono 2 elementi nascosti con lo stesso nome e con lo stesso id.

Di conseguenza quando si seleziona una categoria per la seconda entità custom EntitaB, Alloy valorizza il campo nascosto della prima; questo succede perchè in presenza di più campi con lo stesso id, Alloy prende il primo. Quindi al submit del secondo form, il campo nascosto è vuoto e la categoria non viene di conseguenza salvata.

Dopo un pò di scouting sui sorgenti di Liferay, la soluzione è stata abbastanza semplice da mettere in piedi: differenziare gli id. Ok, ma come?

Nel secondo form, e solo lì, ho sostituito la taglib di Alloy con quella di Liferay andando a specificare esplicitamente tutti gli attributi necessari:

<liferay-ui:asset-categories-selector
    className="<%=EntitaB.class.getName() %>"
    classPK="<%=entitaB.getPrimaryKey() %>"
    contentCallback='<%= renderResponse.getNamespace() + "getSuggestionsContent" %>'
    hiddenInput="assetCategoryIdsEntitaB" />

Il punto focale è l'attributo hiddenInput che mi permette di specificare il nome che dovrà avere il campo nascosto; ma attenzione perchè, affinchè tutto funzioni, è necessario che il valore dell'attributo hiddenInput inizi con assetCategoryIds; infatti solo in questo modo il ServiceContext è in grado di recuperare correttamente i dati dalla request.

Enjoy!

Il form navigator di Liferay

marcello marangio — Wed, 13 Mar 2013 19:57:59 GMT

Spesso mi capita di sviluppare funzionalità in Liferay, specialmente riguardanti l'interfaccia utente, di perdere tantissimo tempo nel perfezionare una routine javascript che faccia sparire un DIV, che ne evidenzi un'altro o che ne posizioni un'altro ancora.

Poi, dopo giorni di lavoro, mi accorgo che c'e' un oggetto in Liferay che fa esattamente quello che voglio, con 2 righe di codice.

E' questo il caso della taglib liferay-ui:form-navigator: è quel box azzurro che si trova alla destra di molte form del pannello di controllo, come ad esempio la gestione utente o la gestione di un site.

Ovviamente l'aspetto grafico è governato dai CSS per cui è utilizzabile anche al di fuori del control panel e personalizzabile come tutto in Liferay.

Per utilizzare il form navigator occorre importare le seguenti taglib:

<%@ taglib uri="http://alloy.liferay.com/tld/aui" prefix="aui" %>
<%@ taglib uri="http://liferay.com/tld/ui" prefix="liferay-ui" %>
<%@ taglib uri="http://liferay.com/tld/util" prefix="liferay-util" %>

Il form navigator si usa così nella home.jsp (o comunque si chiami):

<portlet:actionURL name="saveAll" var="saveAll"/>

<aui:form action="<%=saveAll%>" name="form">

<liferay-ui:form-navigator

    backURL="<%=backURL %>"
    categoryNames="<%= categoryNames %>"
    categorySections="<%= categorySections %>"
    formName="form"
    htmlTop="<%=htmlTop %>"
    htmlBottom="<%=htmlBottom %>"
    jspPath="/sections/" 
    showButtons="<%=true %>"
/>
</aui:form>

dove:

backUrl: (opzionale) è la URL associata al pulsante Cancel

categoryNames: è uno String array con le label delle sezioni (nell'esempio, dopo la localizzazione delle label: User Information, Identification, Miscellaneous)

categorySections: è uno String[ ][ ] che contiene le voci di ogni sezione; all'i-esimo categoryName corrisponde l'i-esimo categorySection[ ]. Nell'esempio, categorySections[0]={"details","password","organizations","sites","usergroups","roles","personal_site","categorization"}

formName: (opzionale) il nome della form che racchiude il form-navigator

htmlTop: (opzionale) è il pezzo di codice html che andrà al top del form navigator

htmlBottom: come sopra, ma sotto :-)

jspPath: è il path che contiene i files jsp corrispondenti alle categorySections: nell'esempio, esiste una pagina password.jsp, una pagina organizations.jsp etc; il file si deve chiamare come la stringa contenuta nell'array e non come la sua versione localizzata a schermo.

showButtons:(opzionale) di default a true, serve per visualizzare o nascondere la button bar con Save e Cancel.

In sostanza la taglib crea un div nascosto per ogni pagina jsp che trova nel jspPath e che corrisponde a una voce di categorySections; poi crea il codice per gestire i click sui link del menù, per evidenziare il link cliccato, visualizzare il div corrispondente e nascondere quello attualmente visualizzato.

Il pulsante Save esegue l'action della form che racchiude il form-navigator (nel mio caso"saveAll"); la form conterrà la somma di tutti gli elementi html inseriti in tutte le categorySections.

Le pagine jsp delle varie sections possono essere complicate a piacere, tanto da poter includere altre form con altre actions, o risultati di ricerca con il search-container, anche paginati etc.

Piccolo problema: se la pagina jsp contiene una form che fa POST su un'action, al ritorno dall'elaborazione il browser atterrerà sulla pagina principale, visualizzando la prima section (questo perchè devo sempre scrivere actionRequest.setRenderParameter("jspPage","home.jsp") e non posso impostare una sottopagina nel renderparameter. Di conseguenza se sto editando, ad esempio, i ruoli dell'utente ad ogni "add" LR ritorna sui dettagli. Il trucco c'e', ma non si vede: con un po' di javascript viene reimpostata la pagina corretta subito dopo, per questo tutto sembra filare liscio.

Purtroppo questa cosa non è automatica, cioè non è inclusa nel taglib del form-navigator, per cui occorre industrarsi un pò.

Studiando, come al solito, il funzionamento del codice html con google chrome, ho visto che per ogni categorySection il div che contiene la pagina corrispondente ha id <portlet:namespace/>nomeCategorySection

Il link che lo fa apparire ha id <portlet:namespace/>nomeCategorySectionLink

la classe css che fa sparire il div è aui-helper-hidden-accessible,

mentre quella che fa apparire un div o visualizzare il link come selezionato è selected

La mia soluzione prevede che ad ogni action delle varie categorySections venga impostato un request attribute che contiene il nome della pagina da visualizzare.

Ad esempio, nel mio caso esiste una categorySection "video" e una pagina "video.jsp" che contiene a form che invoca l'action saveVideo, la cui ultima istruzione è

actionRequest.setAttribute("page2show", "video");

Alla fine della jsp home.jsp che contiene il form navigator ho inserito queste istruzioni jquery:

<script type="text/javascript">
$('#<portlet:namespace/><%=page2show%>').addClass("selected");
$('#<portlet:namespace/><%=page2show%>').removeClass("aui-helper-hidden-accessible");
$('#<portlet:namespace/>primaSection').addClass("aui-helper-hidden-accessible");
$('#<portlet:namespace/>primaSection').removeClass("selected");
$('#<portlet:namespace/>primaSectionLink').parent().removeClass("selected");
$('#<portlet:namespace/><%=page2show%>Link').parent().addClass("selected");
</script>

Nel mio caso "primaSection" è la prima categorySection.

Le ultime 2 istruzioni impostano i link. La struttura del menù html che si vede nell'HTML della pagina è simile alla seguente:

<ul>
<li class="selected">
<a id="<portlet:namespace/>primaSectionLink">
</li>
<li class>
<a id="<portlet:namespace/>videoLink">
</li>
</ul>

La selezione del menù viene implementata con una classe dell'elemento LI (che non ha id) che racchiude il link; a questo sono dovute le due modifiche alle classi css del parent().

In sostanza, al ritorno da ogni action nascondo il primo DIV, deseleziono il link corrispondente, visualizzo il DIV deciso nell'action e seleziono il link corrispondente.

Probabilmente esiste una soluzione più liferay-istica, ma questa funziona bene ed è molto semplice.

Spero possa esser d'aiuto.

Buon lavoro!

Marcello

URL parlanti anche quando linkiamo dal CMS

Jader Jed Francia — Sat, 09 Mar 2013 16:12:32 GMT

Spesso utilizzando le strutture per i web content di Liferay utilizziamo il tipo "Link a pagina": questo speciale tipo di dato permette al contributore, in fase di data entry, di selezionare da un comodo select box una pagina del sito, senza doverne mettere a mano il nome o altro.

All'interno del template di rendering del contenuto, poi, stampiamo il valore che il campo contiene ma il link che viene generato mostra solamente l'id della pagina e non il friendly url.

Lato Liferay, questo è poco male: il sistema, infatti, è in grado autonomamente di riconoscere l'indirizzo e di caricare la pagina relativa all'id, senza "turbare" la user experience del navigatore.

Peccato che i nostri amici della SEO poi vengono da noi e si lamentano che le pagine non hanno il nome parlante!

Quindi? Che fare??

Beh, un po' di velocity e tutto si sistema!

Ecco qui un bello snippet già pronto all'uso che, dato l'id della pagina letto dal campo contribuito in fase di data entry è in grado di generare il link usando la friendlyUrl:

#set ($service =

$serviceLocator.findService(

"com.liferay.portal.service.LayoutLocalService"))

#set ($myGroup = $getterUtil.getLong($groupId))

#set ($myLayoutId = $getterUtil.getLong($Linkpagina.getData()))

#set ($myLayout = $service.getLayout($myGroup, false, $myLayoutId))

<a href="$myLayout.getFriendlyURL()"><h2>$titolo.getData()</h2></a>

Che cosa ne pensate?
Facile, no? :)

Un'ultima raccomandazione, però: per poter utilizzare la variabile $serviceLocator dentro al vostro template velocity dovete prima valorizzare a stringa vuota questa property dentro al vostro portal-ext.properties:

journal.template.velocity.restricted.variables

Questo perché, di default, è valorizzata così:

journal.template.velocity.restricted.variables=serviceLocator

quindi la variabile viene inibita all'interno dei vostri template!

Alla prossima! :)

Generazione miniature con Liferay 6.1.1

Marco Napolitano — Fri, 22 Feb 2013 13:35:53 GMT

Lavorando con le proprie entity custom può capitare di dover manipolare delle immagini e, come spesso succede, di dover creare delle miniature di tali immagini.

Chiaramente è sempre possibile creare tutto a mano e salvarlo poi nella document library, ma perchè farlo quando Liferay è in grado di farlo al posto nostro?

La soluzione è incredibilmente semplice ma richiede alcune spiegazioni:

ImageProcessorUtil.generateImages(fileVersion);

Innanzitutto... cos'è fileVersion?

Si tratta di un oggetto che contiene alcune meta informazioni sulla nostra immagine (o meglio, sul file generico contenuto nella Document Library) e lo possiamo ottenere nel seguente modo attraverso le classi di utility della Document Library:

DLFileEntry imageDLFileEntry = DLFileEntryLocalServiceUtil....

long fileVersionId = imageDLFileEntry.getFileVersion().getFileVersionId();

FileVersion fileVersion = DLAppLocalServiceUtil.getFileVersion(fileVersionId);

Ecco, questo è tutto il codice che deve essere scritto. Ma poi, cosa succede?

Succede che Liferay ricava da fileVersion tutte le informazioni sull'immagine e tenta di generare 3 distinte miniature: quella di default e 2 custom. Sì ok, ma le dimensioni dove le imposto?

Le dimensioni si possono impostare sovracrivendo alcune property di portale, in particolare:

dl.file.entry.thumbnail.max.height=128 dl.file.entry.thumbnail.max.width=128 dl.file.entry.thumbnail.custom1.max.height=200 dl.file.entry.thumbnail.custom1.max.width=200dl.file.entry.thumbnail.custom2.max.height=250 dl.file.entry.thumbnail.custom2.max.width=250

Volendo, le dimensioni di default si possono anche impostare direttamente dal pannello di controllo di Liferay, nella sezione Server -> File Upload.

Ricordate che le dimensioni non rappresentano l'altezza e larghezza esatta della miniatura, ma le dimensioni massime ossia quelle del riquadro all'interno del quale verrà visualizzata la miniatura; quindi non ci sono problemi di deformazioni perchè l'immagine viene scalata per rientrare nel riquadro.

Quindi quello che succede è che Liferay va a cercare i valori di queste property e se sono diversi da zero, genera una miniatura per ogni tipo e la salva nella Document Library.

Bello! Ma adesso come le visualizzo? Anche questo è abbastanza semplice!

Innanzitutto dobbiamo generare l'indirizzo completo dell'immagine originale e lo facciamo attraverso le solite librerie di Liferay:

String imageUrl = DLUtil.getPreviewURL( DLAppLocalServiceUtil.getFileEntry(fileEntry.getFileEntryId()), null, themeDisplay, StringPool.BLANK, false, true);

Il significato dei parametri è il seguente:

DLAppLocalServiceUtil.getFileEntry(fileEntry.getFileEntryId()), serve per recuperare dalla Document Library l'immagine;
null, rappresenta la versione del file ma a noi interessa l'ultima e lo mettiamo a null;
themeDisplay, come farselo mancare?
StringPool.BLANK, parametri aggiuntivi della queryString;
false, non vogliamo che nella URL venga aggiunto il numero di versione;
true, vogliamo una URL assoluta.

La chiamata sopra genera una URL simile alla seguente:

http://localhost:8080/documents/15067/28230/filename.jpg/ 67979c90-ab51-42ed-b3c8-d3721dfafecd

Inserendo la URL in un browser potremmo vedere l'immagine grande. E la miniatura?

Per visualizzare la miniatura è sufficiente aggiungere un parametro alla URL:

String thumbUrl = HttpUtil.addParameter(imageUrl, "imageThumbnail", 1);

Il parametro imageThumbnail serve proprio a richiedere a Liferay di fornirci la miniatura, e può assumere 3 valori distinti:

1, per visualizzare la miniatura di default;
2, per visualizzare la miniatura custom1;
3, per visualizzare la miniatura custom2.

Ad esempio (lo spezzo per motivi tipografici):

http://localhost:8080/documents/15067/28230/filename.jpg/ 67979c90-ab51-42ed-b3c8-d3721dfafecd?imageThumbnail=1

Enjoy!

Deployare portlet custom da pannello di controllo con Liferay 6.1.1

Marco Napolitano — Fri, 15 Feb 2013 08:46:06 GMT

Chi di voi ha avuto modo di lavorare con Liferay 6.1.1 si sarà reso conto di un piccolo problema: non è più possibile, attraverso il pannello di controllo, fare l'upload di un WAR della propria portlet (tema o layout che sia).

Il motivo è legato alla recente introduzione del Marketplace e ad una banale svista che ha inibito il caricamento dei WAR.

Ma niente paura, perchè se ne sono accorti ed hanno rilascito un apposito plugin per ovviare al problema: basta accedere alla sezione Utility del Marketplace e cercare Private Plugin Installer CE.

Una volta installato, accedendo alla sezione Plugins Installation del portale, troverete un nuovo tab Private Plugin Installer con il vecchio funzionamento.

Dockbar menù e portlet "rapide"

Jader Jed Francia — Wed, 23 Jan 2013 07:07:44 GMT

Quando installate Liferay 6.1 la nuova dockbar mostra questa configurazione iniziale:

Quante volte avete pensato "sarebbe molto comodo avere già qui la portlet che uso più spesso" ma, per pigrizia o perché non è mai una priorità non l'avete mai fatto.

Beh, da oggi potete farlo senza perderci dietro troppo tempo!

Vi basterà modificare questa property aggiungendola al vostro portal-ext.properties:

##

## Dockbar Portlet

##

#

# Set the portlet ids that will be shown directly in the "Add Application"

# menu.

#

dockbar.add.portlets=56,101,110,71

Come vedete vi basta modificarla indicando gli id dei vostri portlet ed il gioco è fatto!

Un'altra incredibile feature ottenuta solamente configurando e non sviluppando! ;)

Alla prossima!

Import / export Liferay lar con eccezione

Jader Jed Francia — Tue, 22 Jan 2013 16:12:25 GMT

Tutti avrete pensato che il meccanismo di import / export nativo di Liferay, quello che vi permette di trasferire all'interno di un file LAR (Liferay Archive) le vostre singole righe del database come file XML fosse una vera figata!

La possibilità di sviluppare su un database di test e poi "esportare e importare" su un database di produzione potenzialmente differente rispetto a quello dal quale avete esportato, senza preoccuparvi di nulla, è indubbiamente una funzionalità che chi, come noi, sviluppa progetti apprezza to-cour.

Peccato che molti lamentano che, al momento dell'import, vengano sollevate eccezioni incomprensibili anche quando esportano solamente qualche pagina di prova!

Lo so: la metà dei miei capelli bianchi è data dal meccanismo di import / export dei LAR di Liferay, soprattutto perché questo meccanismo è anche alla base della pubblicazione da staging verso active, sul quale ho già scritto qualche cosa in passato.. :)

Vorrei però condividere con voi un paio di cose che, nella versione 6.1 di Liferay, si deve considerare quando si fa questo tipo di operazione, così che voi possiate beneficiare dei miei capelli bianchi senza farvene troppi dei vostri! ;)

Queste sono le due regole auree che vi consiglio di controllare __SEMPRE__ quando il meccanismo di import si rompe:

il portale dal quale avete esportato ha la lingua di default UGUALE al portale sul quale state cercando di importare
tutte le strutture e i template dell'applicazione del CMS (il Journal..) NON contengono spazi all'interno dei nomi!

E badate bene: per il punto 2 intendo _in tutti i nomi_ anche quelli delle lingue tradotte!!

Escludo ovviamente che stiate provando ad esportare / importare da versioni diverse di Liferay, perché questo è un problema già noto.

Spero che con questi due accogimenti riusciate a importare / esportare contenuti senza diventare pazzi!!

Ovviamente se poi avete ancora eccezioni, il consiglio, aimè, è sempre il solito: attaccate il debugger e.. Buon lavoro! ;)

Alla prossima!

Liferay e Direct Web Remote

Marco Napolitano — Thu, 29 Nov 2012 16:22:27 GMT

Chi lavora con Liferay molto probabilmente conosce il Service Builder e tutto lo strato di persistenza che esso genera.

Però forse non tutti sanno che Liferay è in grado di generare e di mettere a disposizione il medesimo strato di persistenza direttamente in pagina, con Javascript, effettuando in maniera del tutto trasparente le chiamate Ajax necessarie.

Vediamo come fare... e poi mi ringrazierete!

Innanzitutto create in Eclipse un progetto portlet; per comodità chiamatelo DirectWebRemoteTest (così coincidono gli esempi di codice sotto). Aggiungete anche il suo file XML del Service Builder; dopodichè inserite questa entità di prova:

<entity name="Car" local-service="true" remote-service="true" json-enabled="true"> <column name="carId" type="long" primary="true" /> <column name="model" type="String" /> <column name="cabrio" type="boolean" /> <column name="hp" type="int" /> <order by="asc"> <order-column name="model" /> <order-column name="cabrio" /> <order-column name="hp" /> </order> </entity>

Non entro nel dettaglio della entità, che dovrebbe risultare ovvio, ma segnalo solamente i 2 attributi in grassetto che devono essere impostati a true.

A questo punto lanciamo uno dopo l'altro i seguenti 2 target dello script Ant del progetto:

build-service;
build-wsdd.

Una volta terminata l'esecuzione dei 2 target, è già stata creata gran parte di quello che ci serve; prima di procedere dobbiamo decidere quali metodi devono essere accessibili via Javascript in pagina. Supponiamo quindi di voler esporre i metodi:

getCar(long carId), che restituisce la singola entità;
getCars(), che restituisce tutte le entità.

Apriamo quindi la classe CarServiceImpl che, essendo appena stata generata, sarà vuota.

Attenzione: la classe da usare è CarServiceImpl e non CarLocalServiceImpl.

Una volta aperta la classe, aggiungiamo i 2 metodi da esporre come di seguito:

public CarSoap getCar(long carId) throws SystemException { return CarSoap.toSoapModel(carPersistence.fetchByPrimaryKey(carId)); } public CarSoap[] getCars() throws SystemException { return CarSoap.toSoapModels(carPersistence.findAll()); }

Come sono strutturati questi metodi?

Innanzitutto notiamo l'utilizzo della classe CarSoap, generata dal Service Builder, che di fatto è un wrapper del model Car. Dopodichè il contenuto di ciascun metodo non è altro che una normale chiamata allo strato di persistenza, wrappata però dalla classe CarSoap che converte gli oggetti restituiti, in modo da avere in pagina qualcosa di utilizzabile.

A questo punto lanciamo nuovamente uno dopo l'altro i 2 target dello script Ant del progetto:

build-service;
build-wsdd.

Una volta terminata l'esecuzione dei 2 target, apriamo il file docroot/js/service.js; dovreste avere una cosa del genere:

Liferay.Service.register("Liferay.Service.dwr", "it.dvel.dwr.portlet.service",

"DirectWebRemoteTest-portlet"); Liferay.Service.registerClass(

// Liferay.Service.dwr rappresenta una sorta di namespace

// "Car" è il nome dell'oggetto Javascript Liferay.Service.dwr, "Car", { getCar: true, // questo è il nome del primo metodo getCars: true // questo è il nome del secondo metodo } );

La parte cruciale è tutto quanto segue la prima riga, ossia la registrazione della classe Car ed il censimento dei metodi che abbiamo esposto in precedenza. Questo file non deve essere manipolato dallo sviluppatore, vi ho solo mostrato come era stato modificato dal Service Builder.

A questo punto, chiamate un vostro amico e fategli inserire qualche record nel db...

Una volta inserito qualche record in tabella, possiamo procedere con l'ultimo step: il codice da inserire in pagina.

La prima cosa fondamentale è inserire il riferimento al file service.js che abbiamo visto prima; Liferay non lo inserisce da solo, quindi occhio a non dimenticarlo.

Dopodichè ho inserito un pò di codice HTML per posizionare alcuni <div> che verranno riempiti mediante Alloy; niente di che, fate solo caso al valore di id usato.

Infine, il codice vero e proprio, al caricamento della pagina invoco prima un metodo (che mi restituisce un unico record) poi l'altro (che li restituisce tutti); oh è solo un esempio!

Qual'è la sintassi esatta dell'invocazione? E' tutto quanto contenuto nel blocco Liferay.Service.registerClass del file service.js, ossia il namespace ed il nome dell'oggetto Javascript, seguito dal nome del metodo:

Liferay.Service.dwr.Car.getCar(<A>, <B>);

Ogni metodo generato da Liferay ed utilizzabile in pagina ha 2 parametri.

Il primo parametro rappresenta un oggetto JSON contenente tutti i parametri; nel caso non ci siano parametri va comunque passato un oggetto JSON vuoto (ossia {}).

Il secondo parametro è la funzione di callback che viene invocata al termine dell'esecuzione del metodo dello strato di persistenza (ossia quello implementato nella classe CarServiceImpl); il parametro della funzione di callback (il nome è a scelta dello sviluppatore) è l'oggetto restituito dal metodo nella classe CarServiceImpl. Quindi per il metodo getCar il parametro è di tipo CarSoap; mentre per il metodo getCars il parametro è di tipo CarSoap[].

A questo punto potete farne quello che volete.

Enjoy!

Liferay e refresh di una portlet con Alloy UI

Marco Napolitano — Mon, 12 Nov 2012 11:16:46 GMT

Recentemente mi è capitato di dover gestire una situazione un pò "articolata" relativamente all'interazione in pagina tra 2 portlet, con Ligeray 6.1.1.

Senza entrare nel dettaglio, poco interessante per il lettore, segnalo solamente che non era possibile utilizzare nè public render parameter nè eventi.

Pertanto, in un momento di euforia (o di follia...), mi è venuto in mente di tentare di effettuare da una portlet il refresh di un'altra portlet, senza passare dal server ma facendo tutto in pagina con Alloy.

Dopo un pò di prove e di reverse engineering sui sorgenti del portale ecco la soluzione, quasi troppo semplice, che vi riporto nel caso vi servisse:

<aui:script use="aui-base">

var data = {

portletAjaxable: true,

param1: value1,

param2: value2,

... }; Liferay.Portlet.refresh('#p_p_id_<PORTLETID>_', data);

</aui:script>

Cominciamo dal fondo per capire come funziona.

La funzione da invocare si chiama, guarda caso, refresh ed è contenuta nell'oggetto globale Liferay.Portlet; tale funzione richiede 2 parametri:

il primo parametro è l'identificativo (in termini di HTML) del contenitore della portlet e si ricava unendo il prefisso #p_p_id_ con l'identificativo della portlet che deve essere refreshata (ad esempio 2_WAR_MiaPortlet), il tutto chiuso dall'underscore (occhio a non dimenticarlo!);
il secondo parametro è un oggetto JSON contenente gli eventuali parametri da inviare alla portlet.

Quello che succede quando la funzione refresh viene invocata è una chiamata Ajax di tipo renderURL a cui vengono passati tutti i parametri. Pertanto nel metodo doView della seconda portlet è possibile recuperare i parametri normalmente e fare quello che serve:

@Override public void doView(RenderRequest renderRequest,

RenderResponse renderResponse)

throws IOException, PortletException {

String value1 = ParamUtil.getString(renderRequest, "param1");

String value2 = ParamUtil.getString(renderRequest, "param2");

// altri parametri...

renderRequest.setAttribute("param1", value1);

renderRequest.setAttribute("param2", value2);

// altri parametri...

super.doView(renderRequest, renderResponse);

}

Enjoy!

Configurare virtual host per domini con caratteri non-ASCII

Simone Celli Marchi — Sat, 10 Nov 2012 19:12:51 GMT

Ebbene si, quel giorno è arrivato. Il giorno in cui un cliente ci ha chiesto di gestire un dominio contenente caratteri non-ASCII (nel caso specifico lettere accentate).

Da che mondo è mondo, cioè da quanto esistono i DNS, i nomi di dominio posso contenere solamente caratteri ASCII it.wikipedia.org/wiki/ASCII#Tabella_dei_caratteri, escludendo di fatto non solo tutti gli ideogrammi della lingua araba, cinese, giapponese, ecc. ma più semplicemente anche le nostre e care lettere accentate.

Anni fa qualcuno però ha deciso che questa ingiustizia doveva finire e ha voluto a tutti i costi che venissero accettati anche domini con caratteri non-ASCII. Ma ormai la frittata era fatta, perché tutti i protocolli su cui si basa internet utilizzano codifiche ASCII. Ma questo qualcuno voleva a tutti i costi questi domini internazionali it.wikipedia.org/wiki/Nome_di_dominio_internazionalizzato perciò ha deciso bene di inventarsi una codifica chiamata Punycode it.wikipedia.org/wiki/Punycode.

Senza entrare nel dettaglio dell'algoritmo di codifica (che secondo me non l'ha capito nemmeno quello che l'ha inventato) basta sapere che punycode non fa altro che "convertire" un dominio non-ASCII in una stringa ASCII. In particolare viene aggiunto al dominio un prefisso xn-- seguito dal nome del dominio al quale vengono sostituiti i caratteri non-ASCII con caratteri ASCII.

Ad esempio, il dominio www.caffè.it viene confertito in www.xn--caff-8oa.it.

I browser recenti (IE a partire dalla versione 6 tramite l'utilizzo di un plugin) sono in grado di gestire la codifica punycode, perciò quando digitate l'URL http://www.caffè.it si occuperanno in maniera totalmente trasprarente per l'utente di convertire la URL in http://www.xn--caff-8oa.it. Perciò il vostro browser farà prima una query al DNS utilizzando www.xn--caff-8oa.it e invierà la richiesta al web server sempre utilizzando l'hostname www.xn--caff-8oa.it.

Detto ciò, come dovrò configurare Apache, Tomcat o qualsiasi altro webserver/application server? Semplicemente utilizzando il dominio nel formato ASCII. Nel nostro caso:

ServerName www.xn--caff-8oa.it

Ora vi starete chidendo: ma come faccio a sapere qual'è l'equivalente ASCII del mio dominio non-ASCII. Beh, io non lo so, ma ci sono molti convertitori online che possono diverlo:

mct.verisign-grs.com/conversiontool/convertServlet

www.charset.org/punycode.php

Come fare backup di un DB MySQL

Jader Jed Francia — Wed, 31 Oct 2012 04:51:33 GMT

Ieri, alcuni ragazzi con cui stavo lavorando, hanno avuto la necessità di fare un backup del database di Liferay prima di fare upgrade di versione.

Quando ho visto il modo con cui l'hanno fatto sono rimasto stupito e gli ho chiesto di farmi avere le stringhe che hanno utilizzato!

Siccome è una cosa che hanno fatto da command line senza l'utilizzo dell'interfaccia grafica, ho pensato fosse molto comodo e ve lo riporto qui sotto -sai mai che sugli ambienti di produzione dobbiate fare la stessa cosa e non avete a disposizione un ambiente grafico.. ;)-:

# Prima creo il DB dove metterò i dati

mysqladmin create lr610_bck -u user --password=xxxx

# Poi eseguo un Export / Import

mysqldump -u liferay --password=liferay liferay610 | mysql -u user --password=xxxx lr610_bck

Pratico, semplice e veloce, no? :)

Alla prossima!

Come mostrare i tag di un web content da dentro un template velocity

Jader Jed Francia — Tue, 30 Oct 2012 13:47:31 GMT

Ciao a tutti!

La scorsa settimana, mentre stavo tenendo un corso su Liferay ad alcuni amici, siamo incappati in un caso d'uso che necessitava di mostrare, all'interno di un template di velocity, i tag collegati ad un contenuto realizzato con il CMS interno di Liferay (il Journal, appunto! :)).

Dopo aver combattuto un po' siamo riusciti a realizzare il caso; ho pensato quindi di postare qui la soluzione a beneficio di tutti! :)

Questo il codice:

#set ($tagsService =

$serviceLocator.findService(

"com.liferay.portlet.asset.service.AssetTagLocalService")) #set ($journalArticleResourceService =

$serviceLocator.findService(

"com.liferay.portlet.journal.service.JournalArticleResourceLocalService"))

#set ($longGroupId = $getterUtil.getLong($groupId)) #set ($articleResourcePK =

$journalArticleResourceService.getArticleResourcePrimKey(

$longGroupId, $reserved-article-id.data)) #set ($tagsEntries =

$tagsService.getTags(

"com.liferay.portlet.journal.model.JournalArticle", $articleResourcePK))

Tags: #foreach ($entry in $tagsEntries) #set ($tag = $entry.getName()) #if ($velocityCount != 1), #end $tag#end

E ora un po' di spiegazioni! ;)

Se andate a vedere nel codice dei sorgenti di portale la classe com.liferay.portal.velocity.VelocityVariablesImpl potete vedere tutte le variabili che LR vi passa dentro al template.

Quella che a noi interessa di più è quella che viene passata con la chiave "serviceLocator".

Questo oggetto, infatti, ci permette, attraverso un meccanismo interno a LR, di ottenere, sempre dentro al nostro template velocity, istanze di oggetti Service di LR.

Una volta ottenuti quelli che ci servono, poi, possiamo comodamente invocarne i metodi come faremmo in una classe java o in un file JSP.

Spero d'esservi stato d'aiuto!

Se avete dubbi e/o problemi non esitate a chiedere nei commenti qui sotto! :)

Alla prossima! :)

P.S. Abbiamo pubblicato la pagina del corso su Linkedin; se sei stato nostro cliente scrivici una recensione! :)

Criptare i dati in Java con chiave asimmetrica

Aristide Cittadino — Mon, 24 Sep 2012 10:44:39 GMT

Può capitare di dover realizzare dei moduli di registrazione o di sicurezza per i quali è necessario implementare meccanismi di cifratura a chiave asimmetrica.

In questo breve post si mostreranno dei metodi di utilità per la generazione di chiavi asimettriche con l’algoritmo RSA:

Per generare una coppia di chiavi(pubblica e privata) basta eseguire il seguente codice:

import java.security.KeyPair;

import java.security.KeyPairGenerator;

import java.security.NoSuchAlgorithmException;

import java.security.NoSuchProviderException;

import java.security.PrivateKey;

import java.security.PublicKey;

import java.security.SecureRandom;

KeyPairGenerator keyGen;

keyGen = KeyPairGenerator.getInstance("RSA");

SecureRandom random = SecureRandom.getInstance("SHA1PRNG", "SUN");

keyGen.initialize(1024, random);

KeyPair pair = keyGen.generateKeyPair();

PublicKey dVelPrivateKey = pair.getPrivate();

PrivateKey dVelPublicKey = pair.getPublic();

Il metodo getInstance della classe SecureRandom accetta come argomenti il nome di un algoritmo ed il provider.

Il seguente metodo invece serve per la cifratura/decifratura dei dati:

import javax.crypto.BadPaddingException;

import javax.crypto.Cipher;

import javax.crypto.IllegalBlockSizeException;

import javax.crypto.NoSuchPaddingException;

import java.math.BigInteger;

import java.security.InvalidKeyException;

import java.security.Key;

import java.security.KeyFactory;

private static byte[] doCipher(Key cipherKey,byte[] input,boolean encrypt)throws DVelLicenseException{

try{

Cipher cipher = Cipher.getInstance(XFORM);

if(encrypt)

cipher.init(Cipher.ENCRYPT_MODE,cipherKey);

else

cipher.init(Cipher.DECRYPT_MODE, cipherKey);

return cipher.doFinal(input);

}catch (NoSuchAlgorithmException e) {