Guest

Estrarre asset utilizzando tags e categorie in Liferay 6

Andrea Previati — Fri, 06 Apr 2012 10:56:15 GMT

L'asset publisher è lo strumento fornito out of the box da Liferay per estrarre contenuti dal portale in base a una query costruita settando diversi parametri, tra i quali categorie di appartenenza o tag assegnati all'asset.
I casi d'uso coperti da questo strumento sono molteplici, ma per i requisiti che non dovessero essere soddisfatti dalle possibili parametrizzazioni, vediamo come interrogare l'asset framework per mezzo dell'oggetto AssetEntryQuery.

AssetEntryQuery ci consente di costruire una query specificando quali regole in termini di associazione di tag e categorie devono rispettare i nostri asset: l'esempio di seguito vuole porre particolare attenzione su come utilizzare i metodi setAllTagIds e setAnyTagIds per ottenere diverse combinazioni di risultato.
Lo scenario che vogliamo riprodurre è una classificazione di elementi eterogenei tra mezzi a motore di diversa natura; in particolare i nostri asset saranno:

Motore benzina - tags "benzina"
Motore diesel - tags "diesel"
Fiat Punto 1.2 - tags "benzina", "fiat"
Fiat Punto MJet - tags "diesel", "fiat"
Yamaha Tmax - tags "benzina", "yamaha"
Yamaha 422 Sterndrive Diesel - tags "diesel", "yamaha", "marine"

Entrambi i metodi sopra citati accettano come parametro un array di long, pertanto sarà necessario attenere l'id dei tag o delle categorie che vogliamo utilizzare nella query: le due classi contenenti i metodi per l'estrazione sono sostanzialmente AssetTagLocalServiceUtil e AssetCategoryLocalServiceUtil. Al fine di identificare gli id, può essere utile anche fare riferimento alle tabelle del portale assettag e assetcategory.

Vediamo un primo caso nel quale vogliamo ottenere tutti i mezzi contenenti il tag "diesel":

AssetEntryQuery assetEntryQuery = new AssetEntryQuery(); assetEntryQuery.setAllTagIds(new long[]{17458}); List<AssetEntry> results = AssetEntryLocalServiceUtil.getEntries(assetEntryQuery);

Con questo codice otteniamo tutti gli asset ai quali è associato il tag "diesel", che ha id = 17458.
Il risultato sarà quindi:

Yamaha 422 Sterndrive Diesel
Fiat Punto MJet
Motore diesel

Allo stesso modo, otteniamo tutti i mezzi contenenti il tag "benzina" (id = 17462):

AssetEntryQuery assetEntryQuery = new AssetEntryQuery(); assetEntryQuery.setAllTagIds(new long[]{17462}); List<AssetEntry> results = AssetEntryLocalServiceUtil.getEntries(assetEntryQuery);

Yamaha Tmax
Fiat Punto 1.2
Motore benzina

Vediamo ora un esempio un po' più complesso, che prevede un'intersezione di tag e che dimostra le differenze di funzionamento tra il metodo setAnyTagIds e setAllTagIds.
Voglio estrarre tutti gli i prodotti (asset) del marchio yamaha (id = 17473), motorizzati diesel (id = 17458):

AssetEntryQuery assetEntryQuery = new AssetEntryQuery(); assetEntryQuery.setAllTagIds(new long[]{17473, 17458}); List<AssetEntry> results = AssetEntryLocalServiceUtil.getEntries(assetEntryQuery);

Il risultato sarà:

Yamaha 422 Sterndrive Diesel

in quanto è l'unico asset con l'associazione di entrambi i tag "diesel" e "yamaha"
Se l'esigenza fosse stata invece quella di ottenere tutti gli asset contenenti i tag "diesel" o "yamaha", avremmo dovuto utilizzare il metodo setAnyTagIds:

AssetEntryQuery assetEntryQuery = new AssetEntryQuery(); assetEntryQuery.setAnyTagIds(new long[]{17473, 17458}); List<AssetEntry> results = AssetEntryLocalServiceUtil.getEntries(assetEntryQuery);

Yamaha 422 Sterndrive Diesel
Fiat Punto MJet
Yamaha Tmax
Motore diesel

L'oggetto AssetEntryQuery mette a disposizione metodi per l'utilizzo di altri parametri per restringere ulteriormente la selezione: è possibile settare categorie, className e className id e tutti i metodi fin qui elencati in logica negata.
Infine, la presenza dei metodi setStart e setEnd invita lo sviluppatore a ingegnerizzare il proprio codice utiilzzando il classico searchContainer come elemento per la visualizzazione dei risultati.

Inidicizzazione e ricerca in Liferay

Andrea Previati — Mon, 26 Mar 2012 13:11:46 GMT

Nei post precedenti abbiamo appreso come service builder e asset framework siano gli strumenti principali candidati alla gestione dello storage di dati e metadati all'interno di Liferay. Gli stessi strumenti possono essere opportunamente utilizzati anche per la ricerca, ma le possibilità offerte sono strettamente dipendenti dai metodi esposti dal service builder o dall'asset framework.
Se volessimo effettuare una ricerca full text?
Liferay utilizza nativamente Lucene (http://lucene.apache.org) per effettuare le ricerche all'interno del portale e lo scopo di questo articolo è illustrare come rendere ricercabili le nostre entità.
Occorre innanzitutto normalizzare il nostro formato dati verso un modello basato su Document e Field e saremo noi stessi a definire quali dati appartenenti al nostro modello entreranno a far parte degli indici di Lucene per mezzo delle classi indexer.

Importante: il codice di seguito fa riferimento alla versione 6.0.6 di Liferay. A partire dalla 6.1 alcuni metodi sono stati rifattorizzati, ma le linee guida di seguito descritte sono comunque applicabili.

In liferay-portlet.xml:

<indexer-class> it.dvel.test.indexer.MyEntityIndexer </indexer-class>

La classe deve estendere com.liferay.portal.kernel.search.BaseIndexer e implementare i seguenti metodi:

- getClassNames
Restituisce un array di stringo contenenti i nomi delle classi relative ai model che vogliamo indicizzare.
Esempio:

public String[] getClassNames() { return new String[]{MyEntity.class.getName()}; }

- getPortletId
Restituisce il portletID.

ATTENZIONE: per portletID si intende <portlet-name in portlet.xml>_WAR_<webapp name>. Un errore nell'implementazione di questo metodo causerà NullPointerException nascoste nelle JSP del portale in quanto il valore restituito viene utilizzato per recuperare la classe indexer: se compilato in maniera errata, nessun tipo di validazione vi segnalerà l'errore e sarete costretti a una sessione estenuante di debug.

- getSummary
Restituisce un oggetto di tipo Summary che deve contenere un titolo, una sintesi del contenuto e un url per la visualizzazione dell'elemento.
Esempio:

public Summary getSummary(Document document, String snippet, PortletURL portletURL) { String title = document.get(Field.TITLE); String content = StringUtil.shorten(snippet, 200); String resourcePrimKey = document.get(Field.ENTRY_CLASS_PK); portletURL.setParameter("resourcePrimKey", resourcePrimKey); return new Summary(title, content, portletURL); }

- doGetDocument
Converte l'oggetto passato come parametro in un oggetto di tipo Document.
Esempio:

protected Document doGetDocument(Object obj) throws Exception { MyEntity entry = (MyEntity) obj; long companyId = entry.getCompanyId(); long groupId = getParentGroupId(entry.getGroupId()); long scopeGroupId = entry.getGroupId(); long userId = entry.getUserId(); long resourcePrimKey = entry.getPrimaryKey(); String title = entry.getTitle(); String content = entry.getText(); String description = entry.getText(); Date modifiedDate = entry.getModifiedDate(); Document document = new DocumentImpl(); document.addUID(PORTLET_ID, resourcePrimKey); document.addModifiedDate(modifiedDate); document.addKeyword(Field.COMPANY_ID, companyId); document.addKeyword(Field.PORTLET_ID, getPortletId()); document.addKeyword(Field.GROUP_ID, groupId); document.addKeyword(Field.SCOPE_GROUP_ID, scopeGroupId); document.addKeyword(Field.USER_ID, userId); document.addText(Field.TITLE, title); document.addText(Field.CONTENT, content); document.addText(Field.DESCRIPTION, description); document.addKeyword(Field.ENTRY_CLASS_NAME, MyEntity.class.getName()); document.addKeyword(Field.ENTRY_CLASS_PK, resourcePrimKey); return document; }

ATTENZIONE: fate molta attenzione alle seguenti righe di codice:

document.addKeyword(Field.PORTLET_ID, getPortletId());

e

document.addModifiedDate(modifiedDate);

L'assenza della prima pregiudica il risultato della ricerca, escludendo le vostre entità dal risultato: non verrà lanciato nessun tipo di eccezione e nessun messaggio d'errore verrà loggato; l'assenza della seconda riga, invece, genererà un'inspiegabile "NumberFormatException for input string ''": la string vuota che viene segnalata è esattamente la data di modifica.
Altri due giorni di lavoro risparmiati.

- doReindex
I 3 metodi doReindex vengono utilizzato dal portale in fase di richiesta di reindicizzazione del repository.
Data l'istanza della nostra entità passata come parametro, è possibile effettuare l'aggiornamento utilizzando il metodo
SearchEngineUtil.updateDocument(entry.getCompanyId(), document);

L'array di stringhe presente come parametro in uno dei tre metodi rappresenta le companyIds sulle quali iterare per effettuare in reindex completo. Sarà quindi necessario implementare un ciclo sulle company passate, per ognuna delle quali sarà necessario iterare sui groups associati, per ognuno dei quali sarà necessario iterare sulle entity appartenenti al gruppo in questione. L'operazione di update verrà effettuata esattamente come indicato sopra, per mezzo del metodo SearchEngineUtil.updateDocument.

- doDelete
Questo metodo serve a rimuovere l'indice dal repository e verrà invocato dal portale contestualmente alle operazioni di cancellazione delle nostre entity.
L'implementazione è molto banale:

protected void doDelete(Object obj) throws Exception {     MyEntity entry = (MyEntity)obj;     Document document = new DocumentImpl();     document.addUID(getPortletId(), entry.getGroupId(), Long.toString(entry.getPrimaryKey()));     SearchEngineUtil.deleteDocument(entry.getCompanyId(), document.get(Field.UID)); }

Fine dell'implementazione della classe indexer.

Vediamo ora di le funzionalità di ricerca per mezzo di OpenSearch.
Come per le classi indexer, andiamo a censire in liferay-portlet.xml la classe open search relativa al nostro portlet:

<open-search-class>     it.dvel.test.search.MyEntityOpenSearch </open-search-class>

La classe deve estendere com.liferay.portal.kernel.search.HitsOpenSearchImpl e implementare i seguenti metodi:

- getPortletId
Restituisce il portletID. LO STESSO portletID RESTITUITO NELL'INDEXER.

- getTitle
Restituisce un titolo per la ricerca effettuata

- getSearchPath
Restituisce un path descrittivo del contesto di ricerca
Esempio:

public String getSearchPath() {     return "/c/myentity/open_search"; }

Fine dell'implementazione della classe open search.

Deploy del vostro codice, aggiungete il portlet di ricerca in pagina e...fatto!

Esporre le proprie entity custom come Asset di portale

Jader Jed Francia — Sun, 18 Mar 2012 07:20:43 GMT

Facendo tantissimi corsi su Liferay in giro per l'Italia ho l'opportunità di confrontarmi con differenti gruppi di sviluppo sui casi d'uso specifici dei loro progetti.

La risposta che sempre più spesso do alle domande del tipo "come facciamo a fare questa cosa con Liferay è "fatelo con un asset"! ;)

Per chi conosce già la piattaforma, il concetto di Asset non sarà di certo nuovo. Anzi: è una delle funzionalità che rende il portale "potente e versatile" come noi lo vediamo da fuori!

Nel dettaglio, il portale gestisce due tipi di oggetti: "Resource" e "Asset".

Una "Resource" non è altro che un oggetto inserito all'interno del portale sul quale può insistere il permission system. Ogni entry che fate con i metodi del service builder dovrebbe essere inserita anche nel ResourceFramework, proprio per permettere al sistema di gestione dei permessi di gestirne l'accesso.

Un "Asset", invece, è l'elevamento a "oggetto gestibile dagli utenti" di una risorsa. In poche parole, un Asset non è altro che uno speciale tipo di risorsa che però è compresa dal portale come "oggetto di dominio" che può essere utilizzato, ad esempio, direttamente all'interno dell'AssetPublisher oppure sul quale si possono creare custom fields e collegare tag e categories.

In questo post realizzaremo una nostra entità custom che il portale utilizzerà come Asset.

Come al solito, poniamoci un obiettivo da raggiungere e vediamo come, attraverso il portale, riusciremo a realizzare la funzionalità.

Nel nostro esempio, poniamo di voler creare una entità "Progetto" che possa essere "estratta" dagli utenti solamente configurando l'AssetPublisher.

Per raggiungere questo obiettivo, dovremo agire su quattro fronti:

creeremo la nostra entità con il service builder di Liferay
creeremo le permission per la nostra risorsa
inseriremo la nostra risorsa nel ResourceFramework e nell'AssetFramework
forniremo al portale le informazioni relative a come visualizzare la risorsa

Creare entità custom con il service builder

Per prima cosa dobbiamo creare la nostra entità. Lo scopo di questo post non è quello di spiegare il funzionamento del service builder; quindi andremo velocemente su questo punto.

Vi ricordo però l'articolo che abbiamo scritto su MokaByte relativo a questo tema, al quale potete fare riferimento se volete approfondire il dettaglio della tematica qui esposta.

Molto rapidamente:

create attravero la Liferay IDE un nuovo "Liferay Service Builder"
mappate la vostra entità custom
lanciate il task ant "build-service"
fate refresh del progetto! ;)

Se tutto va come deve, otterrete tutti gli oggetto di modello, persistenza e servizi per gestire l'entità appena mappata.

Creare le permission per una risorsa custom

A questo punto dobbiamo "insegnare" a Liferay a gestire la nostra entità in relazione al permission system.

Questo passo è necessario perchè il portale richiede, per funzionare con il ResourceFramework e l'AssetFramework che siano presenti delle permission sull'entità che vogliamo gestire.

Per raggiungere questo obiettivo dobbiamo creare un file, all'interno della nostra src di progetto che chiameremo portlet.properties.

Fate attenzione! È portlet non portal il nome del file! È molto comune fare questo errore; ve lo segnalo perchè anche io ogni tanto, facendo le cose "di corsa", ci casco! ;)

All'interno di questo file inserite questa riga:

resource.actions.configs=resource-actions/default.xml

Questa istruzione, al momento del deploy, dirà a Liferay dove si trova il nostro file relativo alle action sulle nostre risorse. Gli dice, in sostanza, quali permessi deve permettere di applicare su una risorsa per consentire agli utenti, attraverso l'interfaccia di portale, di configurare i ruoli e le relative permission sia sulla nostra portlet che sulle risorse da essa gestite.

Approfondirò in un post successivo questa tematica, perchè il permission system di Liferay è davvero molto ben fatto e dominarlo correttamente ci può essere di grande aiuto per realizzare soluzioni integrate nel portale! :)

Una volta creato il file ed inserita la riga, dobbiamo creare, sempre dentro alla nostra src di progetto, il file default.xml nel folder resource-actions.

Qui un esempio di questo file:

<?xml version="1.0" encoding="UTF-8"?> <resource-action-mapping> <portlet-resource>

<!-- Qui mappiamo il portlet-name del nostro portlet

letto dal file portlet.xml --> <portlet-name>gestioneprogetto</portlet-name> <permissions> <supports>

<!-- come vedete possiamo usare anche chiavi

custom, figata! :) --> <action-key>ADD_PROGETTO</action-key> <action-key>UPDATE_PROGETTO</action-key> <action-key>DELETE_PROGETTO</action-key> <action-key>VIEW</action-key> </supports> <community-defaults> <action-key>VIEW</action-key> </community-defaults> <guest-defaults> <action-key>VIEW</action-key> </guest-defaults> <guest-unsupported> <action-key>ADD_PROGETTO</action-key> <action-key>UPDATE_PROGETTO</action-key> <action-key>DELETE_PROGETTO</action-key> </guest-unsupported> </permissions> </portlet-resource> <model-resource>

<!-- qui mappiamo il model che abbiamo generato e sul

quale potremo agire per dare le permission --> <model-name>

it.dvel.test.service.builder.model.Progetto

</model-name> <portlet-ref> <portlet-name>gestioneprogetto</portlet-name> </portlet-ref> <permissions> <supports>

<!-- anche qui, volendo, potremmo impostare

azioni custom per il nostro modello;

altra figata! :) --> <action-key>DELETE</action-key> <action-key>PERMISSIONS</action-key> <action-key>UPDATE</action-key> <action-key>VIEW</action-key> </supports> <community-defaults> <action-key>VIEW</action-key> </community-defaults> <guest-defaults> <action-key>VIEW</action-key> </guest-defaults> <guest-unsupported> <action-key>UPDATE</action-key> <action-key>DELETE</action-key> </guest-unsupported> </permissions> </model-resource> </resource-action-mapping>

Credo che il file sopra riportato sia auto esplicativo; nel caso ci fossero domande potete farle commentando questo post! :)
Sarò ben felice di rispondervi!! :D

Una volta salvato questo file, al momento del deploy, Liferay caricherà questo file e mapperà nel permission system queste risorse e le relative azioni configurabili; così che dall'interfaccia del pannello di controllo l'utente possa profilarle secondo le proprie esigenze.

Andiamo avanti! ;)

Inserire la risorsa nel ResourceFramework e nell'AssetFramewok

È qui che accade la magia: ogni volta che inseriamo una entity nel database attraverso gli oggetti del service builder, dobbiamo dire ai due framework sopra citati come gestirle e come mapparle.

La domanda che vi sorgerà spontanea sarà sicuramente "ma perchè non lo fa in automatico il service builder"? :)

Bhe, perchè come sempre accade in Liferay, i progettisti della piattaforma vi lasciano la libertà di fare quello che volete. Ovviamente dandovi la possibilità di scegliere ma mettendovi a supporto tutto il necessario per fare le cose "in fretta e bene"! :)

Nel dettaglio, comunque, prima di procedere con il codice, dobbiamo iniettare nel nostro service gli oggetti che utilizzano l'AssetFramework perchè, al contrario di quelli che gestiscono il ResourceFramework, questi non sono presenti di default nei nostri servizi custom.

Per fare questa iniezione dobbiamo nuovamente agire sul file service.xml.

Andate all'interno della nostra entity "Progetto" e, in fondo a tutto, mettete questa riga:

<reference package-path="com.liferay.portlet.asset" entity="AssetEntry" />

Una volta fatto questo:

rigenerate con il task di ant 'build-service' i servizi
fate refresh del progetto! ;)

Una volta compiuta questa operazione, troverete all'interno dell'oggetto "ProgettoServiceBaseImpl" l'iniezione degli oggetti dell'AssetEntry:

@BeanReference(type = AssetEntryLocalService.class) protected AssetEntryLocalService assetEntryLocalService; @BeanReference(type = AssetEntryService.class) protected AssetEntryService assetEntryService; @BeanReference(type = AssetEntryPersistence.class) protected AssetEntryPersistence assetEntryPersistence;

Ora possiamo inserire le nostre entity custom anche all'interno dell'AssetFramework! ;)

Vediamo come!

Per prima cosa dobbiamo far si che ogni volta che si inserisce / modifica / cancella una entity nel database i due framework sopra citati siano notificati di questa cosa.

Per farlo quindi occorrerà modificare i nostri metodi di persistenza perchè si prendano carico di fare queste operazioni.

Nel dettaglio, quindi, andremo ad agire sulla nostra classe di implementazione, in modo che sia "trasparente" per i nostri client che l'entity sia censita anche in questi framework.

Nel dettaglio, quindi, editate la classe "ProgettoLocalServiceImpl" che trovate tra gli oggetti generati dal service builder.

Qui dovremo aggiungere qualche metodo che sarà poi utilizzato dai nostri client per gestire le entity custom verso il database.

Una nota: noi modificheremo solo la parte "Local"; la parte, cioè, che va verso il database.

Se volete portare questo comportamento anche alle entity gestite con i web service SOAP o REST, potete farlo incapsulando questa logica anche nell'oggetto "ProgettoServiceImpl".

Nella nostra classe di implementazione, aggiungiamo questi medoti:

public Progetto addProgetto(Progetto progetto,

ServiceContext ctx) throws PortalException, SystemException { super.addProgetto(progetto); resourceLocalService.addResources( progetto.getCompanyId(), progetto.getGroupId(),

progetto.getUserId(), Progetto.class.getName(), progetto.getPrimaryKey(),

false, true, true); assetEntryLocalService.updateEntry( progetto.getUserId(), progetto.getGroupId(),

Progetto.class.getName(), progetto.getPrimaryKey(),

ctx.getAssetCategoryIds(), ctx.getAssetTagNames()); return progetto; } @Override public void deleteProgetto(long progettoId) throws PortalException,SystemException { Progetto progetto = getProgetto(progettoId); deleteProgetto(progetto); } @Override public void deleteProgetto(Progetto progetto)

throws SystemException, PortalException { resourceLocalService.deleteResource( progetto.getCompanyId(), Progetto.class.getName(), ResourceConstants.SCOPE_INDIVIDUAL,

progetto.getPrimaryKey()); assetEntryLocalService.deleteEntry( Progetto.class.getName(), progetto.getPrimaryKey()); super.deleteProgetto(progetto); }

Cosa facciano questi tre metodi è evidente: ogni volta che una entity viene aggiunta o rimossa notificano questa operazione anche ai nostri due framework.

Bhe, che ci crediate o no, il più è fatto!

Ora dobbiamo dare una "visualizzazione" del nostro Asset che Liferay utilizzerà ogni volta che un estrattore dinamico o all'interno di una componente d'interfaccia standard -come, ad esempio, il motore di ricerca che analizzerò in un post successivo! :)-

Creazione di un AssetRenderer per un'entità custom

E siamo così arrivati in fondo al nostro lavoro! Dobbiamo ora creare gli oggetti che istruiranno il portale su come visualizzare il nostro Asset!

Le classi che ci interessa creare sono delle estensioni di queste due classi di Liferay:

La factory che produce le view degli Asset: BaseAssetRendererFactory
L'implementazione della nostra view: BaseAssetRenderer

La prima cosa da fare è però, come sempre, dire a Liferay come trattare le nostre classi al momento del deploy; per farlo, quindi, andiamo ad agire sul nostro liferay-portlet.xml ed inseriamo questa riga (dopo il tag "icon", così fate prima che a guardare la DTD.. :)).

<asset-renderer-factory>

it.dvel.test.renderer.ProgettoRenderFactory

</asset-renderer-factory>

Questa riga dirà infatti a Liferay qual'è la nostra implementazione da utilizzare quando deve gestire Asset sull'interfaccia.

Vediamo ora l'implementazione di questa classe; premetto che è una cosa molto semplice da fare: la classe base, infatti, nasconde ed implementa già le funzionalità "core" del portale; a noi non resta che dare una nostra implementazione, in modo che sia "veloce" creare questo tipo di struttura.

Nel dettaglio, ecco la classe <omissis voluto degli import.. :)>:

public class ProgettoRenderFactory extends BaseAssetRendererFactory { @Override public AssetRenderer getAssetRenderer(long classPK, int type) throws PortalException, SystemException { Progetto progetto =

ProgettoLocalServiceUtil.getProgetto(classPK); return new ProgettoAssetRenderer(progetto); } @Override public String getClassName() { return Progetto.class.getName(); } @Override public String getType() {

// Questa, francamente, è una cosa non

// corretta, però così funziona.. :) return "progetto"; } }

Fatto! :)

Questa factory è in grado di fornire al portale la nostra implementazione custom per la visualizzazione degli Asset!

Manca però ancora una classe; quella che fisicamente decide come visualizzare il nostro codice.

Vediamo quindi la seconda classe: ProgettoAssetRenderer.

Anche qui, come prima, omissis voluto degli import..

public class ProgettoAssetRenderer extends BaseAssetRenderer { Progetto progetto = null;

// L'istanza di model da visualizzare ci viene passata dalla

// factory; così noi ce la salviamo internamente

// per riusarla "alla bisogna"! :) public ProgettoAssetRenderer(Progetto progetto) { this.progetto = progetto; } @Override public long getClassPK() { return progetto.getPrimaryKey(); } @Override public long getGroupId() { return progetto.getGroupId(); } @Override public String getSummary(Locale locale) { return progetto.getDescrizione();

// O quello che volete che sia la descrizione.. } @Override public String getTitle(Locale locale) { return progetto.getNome();

// O quello che volete che sia il titolo.. } @Override public long getUserId() { return progetto.getUserId(); } @Override public String getUuid() { return null;

// Nel mio progetto non ho generato gli UUID per la

// mia entity, così qui non ritorno nulla. Se lo avessi

// fatto, però, qui avrei usato il metodo che mi avrebbe

// generato il service builder sulla entity. } @Override public String render(RenderRequest renderRequest, RenderResponse renderResponse, String template)

throws Exception {

// passo in pagina la entity renderRequest.setAttribute("progetto", this.progetto);

// decido, nel caso sia in visualizzazione "completa"

// dell'Asset, quale JSP usare. if (TEMPLATE_FULL_CONTENT.equalsIgnoreCase(template)) { return "/html/gestioneprogetto/progetto_full_template.jsp"; }

// Se ritorno null per il TEMPLATE_ABSTRACT ci penserà

// il portale a generare la view usando title e description

// ovviamente potrei passare anche qui una JSP e fornire

// una mia view custom dell'Asset nel formato lista

// dell'AssetPublisher; semplicemente ritornando la JSP opportuna..

return null; } }

That's it!

Compilate, fate deploy e "provare per credere"! ;)

Le nostre entity saranno presenti all'interno dell'AssetPublisher semplicemente selezionando il nostro model come "discriminante di visualizzazione"; nel sistema di gestione dei ruoli potremo impostare le nostre permission sui modelli e sul portlet e anche dalle preference di portlet vedremo esposte le nostre azioni!

Direi che abbiamo raggiunto l'obiettivo! :)

Ora siete pronti a giocare con il portale come meglio credete! ;D

Fatemi sapere se funziona tutto a dovere; ho scritto questo post di domenica mattina prima di portare mia figlia al parco! :) Tutto il codice che c'è qui riportato, però, è preso da un progetto che funziona e che fa quello che ci eravamo proposti di fare!

A presto! :)

Convenzioni nello sviluppo all'interno di Liferay Portal

Andrea Previati — Thu, 15 Mar 2012 12:08:14 GMT

Liferay è una piattaforma di sviluppo open source, con un buon grado di aderenza alle Java Specification Requests e con una molteplicità di tecnologie disponibili per lo sviluppo di risorse custom.

La flessibilità del portale, però, può portare a una situazione di caos nella quale il medesimo risultato atteso di un'implementazione può essere ottenuto perseguendo molte, a volte troppe, strade: tutto bene nel migliore dei casi, ma un grosso problema a fronte dell'eventuale presentarsi di anomalie di difficile circoscrizione.

Qual è quindi la modalità corretta? Potenzialmente (quasi) tutte, ma può essere una buona idea attenersi a quella che d'ora in poi definiremo la "Liferay way"...ovvero..."come fa Liferay".

Strumenti

SDK e bundle della versione prescelta, meglio se una coppia per ogni progetto: eviterete problemi di identificazione dell'SDK in uso e ogni singola istanza di portale conterrà esclusivamente risorse realative al progetto in corso (portet, hook, temi, ecc...)

Ambiente di sviluppo a vostra scelta, personalmente mi oriento sempre su Liferay IDE, ottimo plugin di Eclipse.

Struttura del progetto

Per un progetto di tipo portlet basato su Liferay MVC Framework, la struttura è esattamente quella generata da Liferay IDE:

All'interno del progetto, utilizzaremo per le nsotre risorse le seguenti convenzioni:

nome progetto: minuscolo, separato da dash (il "trattino" -)

nome portlet: utilizziamo un valore numerico. Esempio:

<portlet>
    <portlet-name>1</portlet-name>
    ...

docroot: ogni portlet dovrebbe contenere le jsp in una struttura di directory a partire dalla root identificata dal percorso /html/portlet/<nome_portlet>. Le parole che compongono il nome del portlet dovrebbero essere separate da underscore (il "trattino basso" _). Esempio:

/html/portlet/my_custom_asset_publisher

All'interno dell'ultima directory posizioneremo le jsp preposte all'inizializzazione delle variabili (init.jsp), alla presentazione della modalità view (view.jsp) ed eventualmente edit.jsp e help.jsp.
Solitamente view.jsp include init.jsp.

configurazione: esistono sostanzialmente due modi per rendere configurabile un portlet: edit mode e configuration. Liferay utilizza il secondo approccio, seguendo il quale sarà possibile implementare una pagina di configurazione accessibile per mezzo del menu contestuale del portlet:

Nel file liferay-portlet.xml occorre definire la configuration action class:

<portlet>
	<portlet-name>1</portlet-name>
	<icon>/icon.png</icon>
	<configuration-action-class>it.dvel.test.portlet.ConfigurationActionImpl</configuration-action-class>

La classe appena censita nel file deve estendere BaseConfigurationAction e implementare due metodi:

public void processAction(
			PortletConfig portletConfig, ActionRequest actionRequest,
			ActionResponse actionResponse)
		throws Exception
		
public String render(
			PortletConfig portletConfig, RenderRequest renderRequest,
			RenderResponse renderResponse)
		throws Exception

processAction salva nelle portlet preferences il contenuto del form presente in configuration.jsp, il cui percorso è restituito dal metodo render.

Standard di codifica

Se almeno una volta avete avuto occasione di analizzare i sorgenti del portale e avete un minimo di buon senso nelle best practices di programmazione e modellazione del software, vi sarete accorti che Liferay dal punto di vista della pulizia del codice fa rimpiangere la più becera delle pagine CGI della metà degli anni '90.

Nelle pagine jsp c'è di tutto: chiamate a servizi, definizione di metodi all'interno di scriptlet Java, inlcusioni di jsp con taglib che, a loro volta, includono jsp.

Personalmente non condivido questo approccio, in quanto crea confusione, rende il codice meno leggibile rispetto a un classico approccio "MVC" e, soprattutto, rende meno efficiente il processo di debug: debuggare una jsp in Eclipse, ad esempio, non è così comodo come debuggare una action e il debug è un'attività fondamentale per capire il funzionamento di Liferay.

Tuttavia a fronte di eventuali richieste di adeguamento agli standard, suggerisco ove possibile di utilzzare i custom tag della libreria aui, preferire implementazioni Javascript per mezzo del framework AlloyUI e modellare la struttra delle vostre jsp utilizzando i tag aui:layout e aui:column.

Fate attenzione anche all'elemento css-class-wrapper del file liferay-portlet.xml: questo valore è la classe wrapper relativa al vostro portlet, per mezzo della quale potrete agevolmente identificare univocamente il vostro portlet dalle classi definite nel tema:

	...	
	<css-class-wrapper>my-liferay-plugin-portlet</css-class-wrapper>
</portlet>

 
.my-liferay-plugin-portlet .content {
...

Liferay 6.1.0 GA1 e StackOverflowError

Marco Napolitano — Wed, 14 Mar 2012 09:14:16 GMT

Liferay mette da tempo a disposizione degli sviluppatori un comodo plugin di Eclipse (www.liferay.com/community/wiki/-/wiki/Main/Liferay+IDE) per gestire tutte le configurazioni ed i deploy; il suo utilizzo consente infatti di creare nuovi progetti (portlet, temi, ...) all'interno del proprio workspace e di deployarli direttamente nel server interno censito in Eclipse, dando la possibilità di gestire proficuamente hot code deploy, debug, ..., senza l'ausilio dello script Ant.

Recentemente ho lavorato per un progetto sulla versione di Liferay 6.1.0 GA1 (Community Edition), secondo le modalità sopra, senza avere troppi problemi imprevisti.

Arrivati ad un certo punto dello sviluppo il server ha iniziato a sollevare inspiegabili eccezioni di tipo StackOverflowError in seguito a qualsiasi tipo di interazione con le portlet custom che erano state sviluppate; di fatto era diventato inutilizzabile.

Dopo alcune prove e ricerche ho scoperto che il problema erano gli hook, nello specifico la presenza del file liferay-hook.xml all'interno del mio progetto custom; non potendo rimuovere il file (necessario all'applicazione), l'unica soluzione è stata quella di rimuovere il mio progetto dal server interno di Eclipse e di ripristinare l'utilizzo dello script Ant. Avvio ed arresto del server rimangono comunque all'interno di Eclipse.

In conclusione esiste un bug all'interno di una classe di Liferay adibita al deploy che genera questo malfunzionamento; il bug è documentato qui, http://issues.liferay.com/browse/LPS-24723, ed è stato risolto già a partire con il rilascio della versione 6.1.1 GA2.

Enjoy!

Modificare il timezone del bundle di Tomcat su Liferay 6.1

Marco Napolitano — Thu, 16 Feb 2012 23:22:53 GMT

State sviluppando su Liferay 6.1 e vi siete accorti che i messaggi di Log4J sono indietro di un'ora e non sempre i test sulle date funzionano?

E' un semplice problema nella configurazione di Tomcat7 fornito in bundle con Liferay, che è impostato su GMT, mentre in Italia siamo su GMT+1.

Per risolvere il problema è sufficiente accedere alla cartella di Tomcat7 e modificare il file bin/setenv.bat, sostituendo la dicitura GMT con GMT+1.

Nel caso in cui stiate utilizzando Tomcat direttamente da Eclipse, dovete modificare le impostazioni del server anche lì: facendo doppio click sul server nella vista Server accederete alle sue impostazioni, tra cui il timezone.

Enjoy!

Thunderbird - Allegati corrotti

Luca Leone — Fri, 16 Dec 2011 08:52:14 GMT

Puo' capitare che thunderbird possa avere problemi nel download degli allegati delle mail.

Purtroppo questo problema non e' risolvibile riscaricando la mail ma bisogna modificare dei parametri di configurazione di thunderbird.

Come prima cosa dobbiamo aprire le preferenze di Thunderbird e cliccare sul tab avanzate.

Arrivati a questo punto per editare il file di configurazione dobbiamo cliccare sul pulsante Editor di configurazione... , questo editor visualizza tutte le opzioni di thunderbird in maniera testuale.

Prima di poter visualizzare i parametri il programma avvisa sul pericolo dell'utilizzo di questo editor ma possiamo procedere senza problemi.

Arrivati a questo punto dovremo cercare attraverso l'uso del filto i seguenti parametri:

mail.server.default.fetch_by_chunks
mail.imap.mime_parts_on_demand
mail.server.default.parts_on_demand

Facendo doppio click su ogni opzione il parametro passera' da true a false.

Ora non ci rimane che chiudere tutte le schermate e far partire la riparazione della casella di posta, cliccando con il tasto destro sulla nostra casella e proprieta'

Cliccando su Ripara la cartella, riscarichera' tutti i messaggi scaricando correttamente anche tutti gli allegati.

Collegare database esistenti a portlet sviluppate in Liferay

Jader Jed Francia — Sun, 11 Dec 2011 15:15:00 GMT

Problema: vi chiedono di scrivere dei portlet per Liferay che leggono dei dati da un database esistente.

Soluzione "sporca": vi fate il vostro accesso ai dati e integrate il database esterno alla vostra portlet.

Soluzione "pulita": istruite il service builder adeguatamente e gli fate wrappare le tabelle dell'altro database, così avrete la stessa modalità d'accesso ai dati che avete quando andate sul database di Liferay e chi usa la vostra API non dovrà impazzire per comprenderla! :)

Vediamo un po' nel dettaglio questa soluzione!

Per prima cosa, istruiamo il Service Builder ad utilizzare il database esterno.

Prima un concetto chiave: su Liferay è possibile specificare per singola entity il datasource da utilizzare. Quindi il grosso del lavoro viene fatto dal framework del Service Builder -e dalle classi che saranno generate-; ora vediamo nel dettaglio un po' di codice.

Creiamo una entity che mappi una tabella esistente nel database target -esterno al database di Liferay-. Di seguito evidenzio i pezzi "importanti", quelli che permettono la magia.. :)

<entity name="TimeSheet" table="public.time_sheet"

local-service="true" remote-service="false"

data-source="intranetDataSource"

session-factory="intranetSessionFactory"

tx-manager="intranetTxManager">

...

</entity>

Come vedete, nel nostro file service.xml, specifichiamo quale dev'essere il data-source da utilizzare, quale il session-factory e quale transaction manager.

È ovvio che chi conosce bene Spring ha già chiaro di che cosa stiamo parlando.

Per gli altri, invece, il concetto è molto semplice: Liferay farà in modo che, per l'entità in questione, siano utilizzate connessioni, persistenza e transazioni su un db diverso e non quelle "dirette" che creerebbe verso il suo database.

Una volta creato il nostro file service.xml dobbiamo buildarlo, in modo da farci generare gli oggetti che ci serviranno dopo.

Per farlo, dal build file del vostro portlet, eseguite il task build-service.

Dopo che il Service Builder avrà generato le classi e gli oggetti a partire dal nostro file, dovremo istruire il framework Spring a creare ed utilizzare gli oggetti che, per ora, abbiamo solo referenziato nel service.xml.

Per farlo, nella META-INF del nostro source folder (quindi docroot/WEB-INF/src/META-INF/), creiamo un file chiamato ext-spring.xml

Dentro a questo file, mettiamoci questo codice:

<?xml version="1.0"?> <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN"

"http://www.springframework.org/dtd/spring-beans.dtd"> <beans>

<!-- Qui specifichiamo il JNDI name da utilizzare

per la nostra connessione. La risorsa JNDI va messa all'interno

del file <liferay_dir>/<tomcat_dir>/conf/context.xml --> <bean id="intranetDataSourceTarget"

class="com.liferay.portal.spring.jndi.JndiObjectFactoryBean"

lazy-init="true"> <property name="jndiName">

<value>jdbc/intranetDB</value> </property> </bean>

<!-- Qui creiamo il nostro data source collegato alla connessione

JNDI che abbiamo referenziato poco sopra. --> <bean id="intranetDataSource"

class="org.springframework.jdbc.datasource.LazyConnectionDataSourceProxy"> <property name="targetDataSource">

<ref bean="intranetDataSourceTarget" /> </property>

</bean> <bean id="intranetHibernateSessionFactory"

class="com.liferay.portal.spring.hibernate.PortletHibernateConfiguration"> <property name="dataSource">

<ref bean="intranetDataSource" /> </property> </bean>

 <bean id="intranetSessionFactory"

class="com.liferay.portal.dao.orm.hibernate.SessionFactoryImpl">

<property name="sessionFactoryImplementor"> <ref bean="intranetHibernateSessionFactory" /> </property> </bean>

 <bean id="intranetTxManager"

class="org.springframework.orm.hibernate3.HibernateTransactionManager"> <property name="dataSource">

<ref bean="intranetDataSource" />

</property> <property name="sessionFactory"> <ref bean="intranetHibernateSessionFactory" />

</property> </bean> </beans>

Una volta che abbiamo creato questo file il gioco è fatto!

Ci basterà deployare il nostro portlet e usare la nostra API Liferay per accedere anche alle tabelle del secondo database!

Spero d'esservi stato d'aiuto!

Alla prossima! :)

Aggiornato il sistema a Java 1.6.0_29? Usate MS SQL? Attenzione al bug! ;)

Jader Jed Francia — Tue, 15 Nov 2011 06:45:53 GMT

Ieri ho installato l'aggiornamento per OSX a java 1.6.0_29 e, dopo qualche minuto, ho lanciato una applicazione che ho realizzato per fare del debug da un cliente.

Problema: l'applicazione non mi loggava!

Memore di una mail di qualche giorno prima dei miei colleghi che mi segnalavano questo problema con la versione del JDK incriminata, ho fatto un po' di debug e ho scoperto che il problema risiede in una classe del JDK incriminato.

Nella versione 1.6.0_29, al momento di creare una connessione JDBC verso SQL Server, rimane appesa la chiamata all'infinito e la VM non riesce ad istanziare la connessione.

Facendo un po' di scouting su internet, ho scoperto che c'è un bug nella versione che ho appena installato! (come dice sempre il mio socio si, sono un uomo fortunato.. ;))

Nel dettaglio, questo è il problema (preso dal bug sul sito di Sun):

Creating a JDBC connection through customer JDBC Driver 2.0, 3.0, 4.0 CTP 3,
or jTDS 1.2.5 driver to a  customer  SQL server 2008R2 database using 
JDK 1.6.0_29 results in an indefinite wait for a connection.
This worked fine on all previous versions from 1.6.0_27.

A questo punto, la soluzione è stata semplice: ho sovrascritto il jar jsse.jar che si trova tra le lib del JDK (è qui dentro che sono specificate le classi incriminate) con lo stesso preso da una versione precedente del JDK e tutto è tornato ad andare senza problemi.

Oppure potete optare anche per le soluzioni proposte da Oracle / Sun:

Revert to Java 1.6.0_27 or earlier version, or upgrade to 1.7.0_01.
Or switch customer database server.
SQL Server 2008, 2005, 2000 all work.

Anche se mi sembravano un pochino forti come soluzioni; per questo ho optato per la sovrascrittura del jar! ;)

Infine, ecco un po' di riferimenti al bug:

Spero d'esservi stato d'aiuto! ;)

Alla prossima! ;)

Pubblicare un contenuto con dei documenti la stage a live: problema di permessi sui file

Jader Jed Francia — Fri, 07 Oct 2011 04:57:53 GMT

Problema: ho un contenuto sull'ambiente di stage che ha, nella sua structure, il collegamento a più documenti della mia document library. Quando pubblico su live questo contenuto, i file che sono in esso referenziati, nonostante io sia __CERTO__ che sull'ambiente di stage hanno i permessi di view per guest, non sono accessibili.

Causa: dalle mie indagini, Liferay 5.2.3, quando pubblica da stage a live un web content, non si porta dietro correttamente le permission dei documenti ad esso collegati, per cui mi ritrovo ad avere stage disallineato con live. Parlo ovviamente a livello di permission del document library.

Nota: non ho verificato se questa cosa accade sistematicamente oppure se è una cosa che accade solo quando faccio determinate operazioni (ad esempio pubblico un documento con le permission sbagliate, pubblico il web content che lo referenzia e quindi, quando in stage vado a modificare le permission, non riesco a sincronizzarle su live). Mi riservo di fare una update a questo post quando riuscirò a riprodurre il problema su un ambiente non di produzione! ;)

Soluzione: la soluzione, che poi è un workaround e non una soluzione.. :|, è quella di pubblicare da qualche parte su live il portlet della document library. Da qui, quindi, andare a sistemare i permessi sui documenti interessati, andando di fatto a sistemare il problema sopra descritto.

È tutto! :)

Come ultima nota vi lascio il mio parere sull'ambiente stage di Liferay 5.2.3. Nel corso di questi anni parecchi capelli bianchi sulla mia testa sono stati dati da questo environment; di fatto l'ambiente di stage è un potentissimo strumento a supporto di chi ha necessità redazionali complesse e un processo di composizione delle pagine e dei contenuti articolato.

La funzionalità presente quindi OOTB del prodotto è indubbiamente importantissima per questo utilizzo.

Mi auguro che sulla 6.0 queste problematiche siano state risolte, perchè altrimenti i miei capelli diventeranno ancora più bianchi e i post come questo sui workaround cresceranno esponenzialmente! ;)

Ma anche di questo vi aggiornerò non appena manderemo live il primo progetto con Liferay 6.0 e l'ambiente di stage abilitato! ;D

A presto!

Duplicare un database in SQL Server 2005

Andrea Tomasello — Fri, 30 Sep 2011 14:08:08 GMT

Se il vostro scopo è creare un nuovo database con identici contenuti di uno già presente, quindi stessa struttura e stessi record, una procedura veloce è la seguente: innanzitutto aprire Microsoft SQL Server Management Studio, selezionare dall'elenco dei database quello che farà da "sorgente" e cliccare col destro. Dal menu a tendina selezionare Task -> Export Data.

Si aprirà un wizard che vi permetterà di selezionare il database sorgente (di default sarà selezionato quello da cui siete "partiti"),

vi chiederà analogamente un database di destinazione, con la possibilità di crearne uno nuovo sul momento.

Si passerà poi alla scelta della copia effettiva della struttura e dei dati o l'inserimento di query per restringere la quantità di dati da migrare o modificarli.

Nella schermata successiva, l'ultima, si potranno scegliere le singole tabelle da migrare ed eventualmente chiedere a SQL Server di farlo all'interno di una transazione.

Gestione dei file XML su Bonita Open Solution

Marco Napolitano — Wed, 31 Aug 2011 09:38:20 GMT

Il formato XML è ormai profondamente diffuso in quasi ogni applicativo, e la suite Bonita Open Solution non è da meno fornendo proprio un tipo di dato specifico per manipolare i dati in formato XML.

Peccato che sembra non esistere una guida che spieghi come utilizzare tale tipo di dato; vediamo quindi come fare.

L'obiettivo è quello di creare un processo attraverso il quale fare l'upload di un file XML e visualizzarne il contenuto. A tale scopo utilizzeremo Bonita 5.5.1 e creeremo il seguente processo (do per scontato che Bonita lo sappiate usare):

Come prima cosa definiamo 2 variabili globali di processo:

xmlData, di tipo XML a cui associare a priori il file XSD che descrive il formato del file ed in cui selezionare a priori l'elemento radice;
xmlFile, di tipo Attachment.

Nel primo task Scegli file creare semplicemente una nuova Entry Pageflow in autocomposizione contenente il widget File per caricare il nostro file XML, da associare alla variabile xmlFile. Tutto molto semplice per ora.

Passiamo al secondo task Visualizza in cui aggiungeremo un connettore di tipo Groovy sull'evento Enter del task. Il codice da inserire nel connettore è il seguente e non fa altro che leggere il contenuto del file xmlFile e memorizzarlo in una stringa:

import org.ow2.bonita.util.AccessorUtil byte[] content = AccessorUtil.getQueryRuntimeAPI().getDocumentContent(xmlFile.UUID) new String(content)

L'output del connettore associarlo alla variabile xmlData, su tutta la variabile (Whole variable).

A questo punto il grosso del lavoro è stato fatto, la variabile xmlData contiene i dati da elaborare; cosa che andremo a fare mediante XPath.

Pertanto aggiungiamo una nuova Entry Pageflow al task Visualizza in cui andremo a visualizzare qualche dato.

Inseriamo un widget di tipo Text e selezioniamo la variabile xmlData dalla combo; comparirà un popup con la struttura dei dati in cui selezionare cosa visualizzare. Verrà generata un'espressione Groovy del tipo (che contiene il percorso XPath):

${providedscripts.BonitaXML.evaluateXPathOnVariable(xmlData, "/NOMETAG/@ATTRIBUTO")}

L'unica cosa fondamentale da segnalare (e ricordare) è che il metodo evaluateXPathOnVariable restituisce una stringa nel caso in cui l'espressione XPath riguardi un attributo o contenga la funzione text(); in tutti gli altri casi restituisce un oggetto di tipo org.w3c.dom.Node (che deve quindi essere manipolato con i suoi metodi).

Purtroppo non viene mai restituito un oggetto org.w3c.dom.NodeList, quindi in caso di liste di tag è conveniente recuperare il nodo che li contiene e poi ciclare su di esso.

Enjoy!

Gestire il concetto di "back" su Bonita Open Solution

Marco Napolitano — Fri, 26 Aug 2011 09:35:54 GMT

Premessa doverosa: Bonita è una piattaforma di Business Process Management e non serve per fare "applicazioni web". Di conseguenza non esiste il concetto di "Back", ossia "ritorna alla schermata precedente" in quanto le schermate sono collegate ai task di un processo e di norma non è bene saltare avanti/indietro.

Tuttavia possono essere casi in cui la retroazione dei task sia un requisito del processo, ad esempio per modificare il valore di un campo.

Vediamo quindi come fare:

come prima cosa definiamo il task di tipo human ed associamo una nuova Entry Pageflow
all'interno della pagina inseriamo 2 pulsanti di submit che definiamo Back e Next
aggiungiamo al task (non al processo) una variabile di tipo boolean che chiamiamo proceed
a questo punto è sufficiente aggiungere a ciascun pulsante una action che imposti il valore di proceed:
- per il pulsante Back assegnamo false a proceed
- per il pulsante Next assegnamo true a proceed
a questo punto creiamo 2 transizioni in uscita dal nostro task: una collegata al task precedente ed una collegata al task seguente
alla transizione precedente associamo la condizione proceed==false
alla transizione seguente associamo la condizione proceed==true o, in alternativa, la impostiamo come Default flow

A questo punto il Bonita Engine è in grado di gestire correttamentre la navigazione tra i task, attivando la transizione giusta a seconda del valore della variabile proceed.

Enjoy!

Ordinare una lista di liste in Groovy

Marco Napolitano — Fri, 26 Aug 2011 08:34:50 GMT

Ordinare una lista in Groovy è un'operazione piuttosto semplice, anche con liste di oggetti complessi. Infatti è sufficiente invocare il metodo sort() come negli esempi seguenti:

// ordinamento di un elenco di numeri

def numbers = [4,2,5,3,1] assert [1,2,3,4,5] = numbers.sort()

// ordinamento di un elenco di stringhe

def letters = [c,d,a,b,e] assert [a,b,c,d,e] = letters.sort()

// ordinamento di un elenco di oggetti in base ai campi

def people = [ new Person(id: 2, name: Marco), newPerson(id: 1, name: Jader), newPerson(id: 3, name: Andrea) ]people.sort{ it.id } // produce [Jader, Marco, Andrea]people.sort{ it.name } // produce [Andrea, Jader, Marco]

Però, nel caso in cui ci si trovi a lavorare con un oggetto di tipo List<List<String>> le cose sono un pò più complesse (ma non poi troppo).

Supponiamo quindi di avere una lista di oggetti che, per qualche motivo applicativo, dobbiamo trasformare in una lista di liste.

Come prima cosa creiamo la nostra lista di liste:

def list = new ArrayList<List<String>>()

// people rappresenta una List<Person>

people.each { person-> def objCols = new ArrayList<String>() objCols.addperson.id // indice posizionale = 0 objCols.addperson.name // indice posizionale = 1
objCols.add person.surname // indice posizionale = 2

//...e così via list.add objCols }

A questo punto è necessario definire un apposito comparatore che effettui il confronto posizionale tra gli elementi.

byName = [ compare:{ a,b-> a[1]<=>b[1] } ] as Comparator

Per capire lo snippet occorre ricordare che siamo in presenza di una List<List<String>> pertanto il singolo elemento della lista è una List<String>; di conseguenza è necessario specificare l'indice posizionale dell'elemento della lista interna che si vuole confrontare, nel nostro caso 1 ossia il nome.

A questo punto è possibile ordinare la lista:

list.sort(byName) // modalità ascendente

list.sort(byName).reverse() // modalità discendente

Enjoy!

Impostare IDfQueryBuilder con attributi repeating multipli

Marco Napolitano — Fri, 05 Aug 2011 10:53:29 GMT

Mi sono recentemente scontrato con un problema apparentemente banale durante la realizzazione di una ricerca custom per un'applicazione Webtop-based.

La problematica era realizzare, tramite l'interfaccia IDfQueryBuilder, una query DQL del tipo:

SELECT *
FROM my_document
WHERE ANY (attr1 = ? AND attr2 = ?);

Entrambi gli attributi attr1 e attr2 sono di tipo repeating e devono essere racchiusi all'interno delle parentesti perchè mi serve fare una ricerca posizionale sui valori degli attributi, ossia una cosa del tipo:

attr1[0]=? AND attr2[0]=?
attr1[1]=? AND attr2[1]=?
attr1[2]=? AND attr2[2]=?
...e così via

Peccato che IDfQueryBuilder non consenta di creare un'espressione composta di quel tipo, ma consente solamente le 2 parti separate:

SELECT *
FROM my_document
WHERE ANY attr1 = ? AND ANY attr2 = ?;

Ecco quindi come fare a risolvere il problema.

Innanzitutto, nella classe Java che prepara la ricerca (il metodo buildQuery per intenderci) è necessario aggiungere le 2 espressioni di ricerca come se gli attributi NON fossero repeating:

IDfQueryBuilder qb = ...
IDfExpressionSet set = qb.getRootExpressionSet();
set.addSimpleAttrExpression("attr1", IDfValue.DF_STRING,
                            IDfSimpleAttrExpression.SEARCH_OP_EQUAL,
                            true, false, "valore");
set.addSimpleAttrExpression("attr2", IDfValue.DF_STRING,
                            IDfSimpleAttrExpression.SEARCH_OP_EQUAL,
                            true, false, "valore");

Dopodichè è necessario modificare il file dfc-dqlhints.xml al fine di forzare la ricerca ad utilizzare la DQL hint ROW_BASED che consente di effettuare una ricerca su attributi repeating multipli senza specificare la clausola ANY.

<Rule>
   <Condition>
      <From>
         <Type>my_document</Type>
      </From>
      <Where condition="all">
         <Attribute>attr1</Attribute>
         <Attribute>attr2</Attribute>
      </Where>
   </Condition>
   <DQLHint>ENABLE(ROW_BASED)</DQLHint>
</Rule>

Questa nuova rule da aggiungere ha il significato: per ogni query fatta sul tipo my_document che includa entrambi gli attributi attr1 e attr2, utilizzare la DQL hint ROW_BASED.

Ecco quindi che la query DQL che viene eseguita dal sistema sarà:

SELECT *
FROM my_document
WHERE attr1 = ? AND attr2 = ?
ENABLE(ROW_BASED);

Enjoy!

Ancora sulle Expando Tables di Liferay

Jader Jed Francia — Fri, 08 Jul 2011 06:12:25 GMT

Alcuni clienti ci hanno chiesto approfondimenti relative all'utilizzo dei campi expando sulle entità custom; siccome potrebbe interessare anche altri, eccoli di seguito anche per voi! ;)

Estrarre un singolo field

Per estrarre un singolo field dal database, Liferay ci mette a disposizione, attraverso la sua tag library, un metodo di utility:

<liferay-ui:custom-attribute

classPK="<%= myEntity.getPrimaryKey() %>"

name="NomeCampo"

className="it.dvel.stupid.custom.model.SimpleTable">

</liferay-ui:custom-attribute>

Questo tag mi consente di estrarre e di visualizzare dal database di Liferay il campo di nome NomeCampo del tipo it.dvel.stupid.custom.model.SimpleTable.

Attenzione: questa tag library restituisce solamente il valore del campo scelto, in formato text field editabile oppure come sola label. Come faccio a pilotare questo rendering? Ma con i permessi, ovvio! ;)

Gestire i permessi sui campi expando

I permessi sui custom fields, attivabili direttamente dal pannello di controllo, sezione Expando, mi consentono di decidere la politica di visualizzazione dei singoli campi.

Nel dettaglio, agendo sulle leve di view e update, possiamo dire indirettamente alla tag library se i miei utenti possono vedere il valore oppure se lo possono anche editare.

La tag library, a runtime, si occuperà per noi di presentare il campo nella maniera più opportuna a seconda dei permessi impostati sui singoli campi!

Casi d'uso in cui usare i campi Expando e i permessi

Bhe, ovviamente ce ne sono un'infinità!

Vi do' i più semplici e i più immediati come riscontro.

Ad esempio, facciamo l'ipotesi che aggiungiamo il campo salario sull'anagrafica dell'utente.

Vorremo fare in modo che:

l'utente possa solo visualizzare il campo (permesso di view)
l'utente amministrativo possa anche modificarlo (permesso di view + update)
gli altri utenti non vedano proprio il campo (togliamo il permesso di view)

Oppure: vogliamo creare una form di data entry, usando i campi Expando, e permetterne il popolamento a due figure differenti.

In questo caso mi basterà giocare sui permessi (come ho spiegato nell'esempio sopra relativo agli utenti) e sarà un gioco da ragazzi farlo! ;)

Spero che questo tip vi sia stato utile! :)

Alla prossima! :)

ExpandoTable sulle vostre entità custom!

Jader Jed Francia — Fri, 01 Jul 2011 18:10:47 GMT

Problema: vorreste poter aggiungere degli attributi custom alle vostre entità a runtime, ma non sapete come fare.

Soluzione: usate le expando tables di Liferay! ;)

Per farlo dovete procedere in questo modo:

Registrare l'entità perchè utilizzi il framework delle expando
Predisporre la JSP per mostrare i campi expando
Predisporre la action per salvare i campi expando

Registrare l'entità perchè utilizzi il framework delle expando

Per registrare un'entità custom al fine di poterla "collegare" alle tabelle expando, dobbiamo creare una classe che estenda com.liferay.portlet.expando.model.BaseCustomAttributesDisplay

Questa classe, infatti, contiene tutta la logica che serve per poter gestire l'interfaccia nel pannello di controllo sulla parte dei custom fields.

Questa è l'implementazione della nostra classe:

package it.dvel.stupid.custom.display;

import it.dvel.stupid.custom.model.*;

import com.liferay.portal.theme.*;

import com.liferay.portlet.expando.model.*;

public class SimpleTableCustomAttributesDisplay extends

BaseCustomAttributesDisplay {

public static final String CLASS_NAME =

SimpleTable.class.getName();

// Qui gli diciamo come si chiama la nostra classe

public String getClassName() {

return CLASS_NAME;

}

// Qui gli diciamo dove trovare l'icona che deve

//usare per la nostra entità

public String getIconPath(ThemeDisplay themeDisplay) {

return themeDisplay.getPathThemeImages() +

"/common/user_icon.png";

}

Una volta creata la nostra classe, dobbiamo dire a Liferay di caricarla quando installiamo il nostro portlet.

Come sempre, dobbiamo andarla a mappare nel liferay-portlet.xml dentro a WEB-INF

<portlet>

<portlet-name>helloworldportlet</portlet-name>

<icon>/icon.png</icon>

...

<custom-attributes-display>

it.dvel.stupid.custom.display.SimpleTableCustomAttributesDisplay

</custom-attributes-display>

...

</portlet>

Predisporre la JSP per mostrare i campi expando

Ok: a questo punto siamo pronti per mostrare nella nostra pagina i campi. Tenete presente che quello che stiamo per fare serve solamente per estrarre gli attributi. Non stupitevi quando, provando, non li vedrete: se non andate prima nel pannello di controllo ad inserire i campi custom, è normale che poi non li vediate.. ;)

Comunque, andate nella vostra JSP e incollate questo codice:

<h3><liferay-ui:message key="custom-fields" /></h3>

<aui:fieldset>

<liferay-ui:custom-attribute-list

className="it.dvel.stupid.custom.model.SimpleTable"

classPK="<%= (myEntity != null) ? myEntity.getPrimaryKey() : 0 %>"

editable="<%= true %>"

label="<%= true %>"

/>

</aui:fieldset>

Ovviamente questo va all'interno di un campo form, perche' dopo i valori che l'utente immetterà dovranno essere passati in post alla nostra action.

Non commento la tag library perchè mi pare sia self explanatory.. ;)

Interessante notare, tuttavia, che posso scegliere di mostrare la lista degli attributi editabile o meno; in questo modo, mettendo true o false, posso scegliere come il componente deve renderizzare i miei campi.

Predisporre la action per salvare i campi expando

Molto bene! A questo punto siamo pronti per salvare i valori immessi dagli utenti sull'interfaccia generata dalla nostra JSP.

Bene, tenetevi forte amici, perchè è qui che si vede tutta la potenza di un framework applicativo come Liferay! ;)

Questo è il codice che salva i valori immessi nel database:

// Ovviamente sono all'interno di un metodo di tipo processAction()..

// Per prima cosa mi serve una istanza di ServiceContext

ServiceContext serviceContext =

       ServiceContextFactory.getInstance(
SimpleTable.class.getName(), actionRequest);        
 SimpleTable table =
     SimpleTableLocalServiceUtil.createSimpleTable(
         CounterLocalServiceUtil.increment(SimpleTable.class.getName()));
 // Faccio tutte le mie set sulla mia entità
 ...
 // Ed ecco dove accade la magia! ;)
 table.setExpandoBridgeAttributes(serviceContext);
  
 // Poi faccio la insert
 SimpleTableLocalServiceUtil.updateSimpleTable(table, false);

That's it! :)

Abbiamo salvato i valori che l'utente immette nella form con uno sforzo minimo! ;)

Come abbiamo fatto?!

La magia accade all'interno dell'oggetto ServiceContext. In breve, questo oggetto è l'implementazione di un pattern che ci consente di avere delle funzionalità common a più oggetti senza avere l'onere di estendere una classe padre.

Come vedete, il framework offre delle utility per accedere ad una istanza di questo oggetto a partire da una request; questo ci offre il vantaggio di disinteressarci completamente della logica di popolamento di questo oggetto, perchè gestita direttamente dal framework, ma ci consente di beneficiare enormemente delle sue funzionalità.

Nello specifico, il serviceContext è l'oggetto all'interno del quale io posso trovare, ad esempio, il companyId o lo scopeGroupId in cui l'utente stà operando.

Altra funzionalità molto importante del serviceContext, ad esempio, è la gestione trasparente dei tags e delle categories che l'utente può scegliere dall'interfaccia di Liferay, ma di questo parlerò più diffusamente in un post successivo! :)

Alla prossima! :)

Referenze

Expando sul wiki di Liferay
ServiceContext sul wiki di Liferay

Documentum - IDfQueryBuilder ed esecuzione subquery DQL

Marco Napolitano — Fri, 01 Jul 2011 13:34:18 GMT

In un precedente blog abbiamo visto come realizzare query DQL su attributi repeating mediante l'oggetto IDfQueryBuilder; quello che vedremo adesso è un pò più complesso e riguarda l'esecuzione di subquery, sempre all'interno di un'applicazione Webtop/WDK.
Supponiamo quindi di dover eseguire la seguente query DQL:

SELECT * FROM my_document1 WHERE my_field IN (SELECT r_object_id FROM my_document2 WHERE ...);

L'idea alla base della soluzione che stiamo per vedere è quella di eseguire la subquery separatamente, utilizzando poi l'elenco dei valori nella clausola IN.
Come prima cose vediamo come eseguire la subquery e ricavare i valori.

protected IDfQueryBuilder buildQuery() throws Exception { //[...] // creazione della query DQL IDfPassThroughQuery query = getSearchInfo().getSearchService()

.newQueryMgr()

.newPassThroughQuery(

"SELECT r_object_id FROM my_document2 WHERE ..."); // si associano alla query creta tutti i DOCBASE presenti

// nella connessione a Documentum IDfEnumeration availableSources = getSearchInfo().getSearchService() .getSourceMap().getAvailableSources(); while (availableSources.hasMoreElements()) { IDfSearchSource source =

(IDfSearchSource) availableSources.nextElement(); query.addSelectedSource(source.getName()); } // creazione del processor della query IDfQueryProcessor queryProc = getSearchInfo().getSearchService()

.newQueryProcessor(query, true); // si esegue la query DQL e si valorizza la lista dei risultati IDfList listForINClause = new DfList(IDfList.DF_STRING); IDfResultsSet resultsSet = queryProc.getResults(); while (resultsSet.next()) { IDfResultEntry entry = resultsSet.getResult(); listForINClause.appendString(entry.getString("r_object_id")); } //[...] }

A questo punto è sufficiente aggiungere la clausola IN al nostro oggetto IDfQueryBuilder ed il gioco è fatto.
IDfExpressionSet expressionSet = qb.getRootExpressionSet(); expressionSet.addValueListAttrExpression("my_field",

IDfValue.DF_STRING, IDfValueListAttrExpression.SEARCH_OP_IN,

false,

listForINClause);

Il punto fondamentale è il metodo addValueListAttrExpression pertanto analizziamone i parametri usati (confrontandoli con la query DQL vista sopra):

"my_field", è il nome del campo su cui dobbiamo fare la ricerca IN;
IDfValue.DF_STRING, è il tipo del campo (stringa, intero, boolean, ...);
IDfValueListAttrExpression.SEARCH_OP_IN, è l'operazione di filtro da eseguire (nel nostro caso IN);
false, abilita/disabilita la ricerca case sensitive;
false, configura l'attributo come repeating in modo che il framework utilizzi la clausola ANY;
listForINClause, elenco dei valori da cercare.

Enjoy!

Documentum - IDfQueryBuilder e query su attributi repeating

Marco Napolitano — Fri, 01 Jul 2011 12:50:50 GMT

Per realizzare una ricerca custom all'interno di un'applicazione web Documentum-based (mediante l'utilizzo di Webtop oppure di WDK) è solitamente necessario creare un'apposito "component" e conseguentemente una classe Java per le eventuali funzionalità custom di business.
Questa classe Java solitamente estende le superclassi AdSearchEx (oppure direttamente AdvSearchExBase) andando a specificare il metodo:
protected IDfQueryBuilder buildQuery() throws Exception;

che si occupa di configurare e restituire un oggetto IDfQueryBuilder contenente la struttura della query da eseguire.
Supponiamo quindi di dover eseguire una query DQL su di un campo di tipo repeating e vediamo come configurare l'oggetto IDfQueryBuilder; la query da eseguire è la seguente (notare la clausola ANY per la ricerca su attributi repeating):

SELECT * FROM my_document WHERE ANY my_field = 'text';

Il codice Java che andremo a scrivere è il seguente:
protected IDfQueryBuilder buildQuery() throws Exception { // si recupera dalla superclasse un oggetto preconfigurato

// su cui lavorare IDfQueryBuilder qb = super.buildQuery(); // in alternativa sarebbe stato possibile creare un nuovo

// oggetto da zero ricordandosi però di configurare

// correttamente la DOCBASE di riferimento // IDfQueryBuilder qb = getSearchInfo().getSearchService().newQueryMgr()

// .newQueryBuilder("my_document", -1, true); // qb.addSelectedSource(getDfSession().getDocbaseName()); // [...] eventuali colonne da restituire in output // si recupera l'insieme delle clausole di WHERE IDfExpressionSet expressionSet = qb.getRootExpressionSet(); expressionSet.addSimpleAttrExpression("my_field",

IDfValue.DF_STRING,

IDfSimpleAttrExpression.SEARCH_OP_EQUAL,

false,

true,

"text"); // [...] eventuali clausole di ordinamento return qb; }

Il punto fondamentale è il metodo addSimpleAttrExpression pertanto analizziamone i parametri usati (confrontandoli con la query DQL vista sopra):

"my_field", è il nome del campo su cui dobbiamo fare la ricerca;
IDfValue.DF_STRING, è il tipo del campo (stringa, intero, boolean, ...);
IDfSimpleAttrExpression.SEARCH_OP_EQUAL, è l'operazione di filtro da eseguire (=, >, <, ...);
false, abilita/disabilita la ricerca case sensitive;
true, configura l'attributo come repeating in modo che il framework utilizzi la clausola ANY;
"text", testo da cercare.

Enjoy!

Utilizzare il captcha in Liferay

Jader Jed Francia — Sun, 26 Jun 2011 19:23:14 GMT

In questo post vediamo come possiamo utilizzare il captcha all'interno delle nostre portlet.

Per prima cosa dobbiamo mostrare l'immagine del captcha sulla nostra pagina, per permettere all'utente di leggerlo.

Per fare questo dobbiamo:

sovrascrivere un metodo nella nostra portlet che viene specificato dal JSR286: serveResource
utilizzare una taglibrary di Liferay per poter mostrare l'immagine

Vediamo l'implementazione del metodo che dobbiamo implementare nella nostra action:

@Override

public void serveResource(ResourceRequest resourceRequest,

ResourceResponse resourceResponse) throws IOException, PortletException {

CaptchaUtil.serveImage(resourceRequest, resourceResponse);

}

Come vedete, questo metodo serve l'immagine utilizzando la classe CaptchaUtil messa a disposizione da Liferay.

Ora dobbiamo mostrare l'immagine nella nostra JSP; per fare questo dobbiamo:

importare la tag library che contiene la facility per il captcha
utilizzare la tag library

Per importare nella JSP la tag library usiamo questo statement:

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

Mentre, per stampare il captcha sulla pagina, utilizzamo questa chiamata:

<portlet:resourceURL var="captchaURL"/>

...

<liferay-ui:captcha url="<%= captchaURL %>" />

La prima chiamata genera, utilizzando la API di portale, la stringa per chiamare il nostro metodo nella action; la seconda, invece, è la faciliy messa a disposizione da Liferay per mostrare in pagina il captcha.

Ora, una volta messo tutto dentro ad un tag form, possiamo andare nel codice a verificare che l'utente immetta correttamente il valore del captcha:

@Override

public void processAction(ActionRequest actionRequest,

ActionResponse actionResponse) throws IOException, PortletException {

try {

// Controllo l'input utente

CaptchaUtil.check(actionRequest);

} catch (CaptchaException e) {

// in caso d'errore segnalo in pagina l'errore

SessionErrors.add(actionRequest, e.getClass().getName());

}

Per gestire in pagina l'errore, possiamo utilizzare le tag library di Liferay:

<liferay-ui:error exception="<%= CaptchaTextException.class %>"

message="Verificare il testo del captcha!" />

<liferay-ui:error exception="<%= CaptchaMaxChallengesException.class %>"

message="Numero massimo di tentativi raggiunti!" />

Se tutto va come deve, abbiamo il captcha nella nostra form di dati e riusciamo a verificarlo senza problemi! ;)

Alla prossima! :)