bloggers bloggers

Marco Napolitano
Messaggi: 68
Stelle: 0
Data: 15/11/17
Jader Jed Francia
Messaggi: 50
Stelle: 0
Data: 22/09/17
Ezio Lombardi
Messaggi: 9
Stelle: 0
Data: 23/06/17
Chiara Mambretti
Messaggi: 25
Stelle: 0
Data: 27/02/17
Serena Traversi
Messaggi: 3
Stelle: 0
Data: 21/07/16
Francesco Falanga
Messaggi: 8
Stelle: 0
Data: 14/06/16
Antonio Musarra
Messaggi: 2
Stelle: 0
Data: 18/11/13
Simone Celli Marchi
Messaggi: 6
Stelle: 0
Data: 09/07/13
marcello marangio
Messaggi: 4
Stelle: 0
Data: 05/07/13
Marco Mancini
Messaggi: 1
Stelle: 0
Data: 05/06/13
Indietro

Esporre le proprie entity custom come Asset di portale

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:

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:

  1. create attravero la Liferay IDE un nuovo "Liferay Service Builder"
  2. mappate la vostra entità custom
  3. lanciate il task ant "build-service"
  4. 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:

  1. rigenerate con il task di ant 'build-service' i servizi
  2. 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:

  1. La factory che produce le view degli Asset: BaseAssetRendererFactory
  2. 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();

// Oquello che volete che sia la descrizione..
}

@Override
public String getTitle(Locale locale) {
return progetto.getNome();

// Oquello 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 JSPe 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!:)

Precedente
Commenti
Aggiungi Commento
Federico Cerminara
Ciao Jader, innanzitutto grazie per il post. Davvero interessante, soprattutto perché introduce alla gestione degli asset che sono comunque poco documentati anche nel manuale Liferay in Action.

Ieri ho provato ad aggiungere i tuoi suggerimenti su un mio progetto (niente di complicato: si tratta di un crud per l’inserimento di entità con un aui: searchcontainer per la visualizzazione della tabella impaginata).
Sono riuscito abbastanza rapidamente ad agganciare una assetEntry al momento della creazione della mia entity ASTProduct. E quando ho caricato la portlet AssetPublisher ho visto con soddisfazione che la entità compariva tra le asset. Adesso la mia intenzione era quella di associare dei tag alla nuova asset. La creazione di un tag è abbastanza semplice anche da codice:

String newTag = "newTag";
long userId = themeDisplay.getUserId();
AssetTagLocalServiceUtil.addTag(userId, newTag, null, serviceContext);

Basta usare i metodi della classe AsseTagServiceLocalUtil ed in particolare il metodo addTag, a cui fornire come parametri l’id dell’utente user, il nome del tag creato, un array di tagProperties (il campo che ho riportato come null) ed il serviceContext. Nel codice mostro come ricavre l’id utente. Per il serviceContext, ho visto su internet che esistono diversi approcci per ricavarlo. Ma non ho le competenze ancora per discriminare quale sia il più utile al caso di volta in volta.

Adesso spulciando nel db di Liferay, ho capito che assegnare un tag ad un asset si traduce nell’inserimento di una tupla nella tabella assetenries_assettags e ho provato, senza successo, a cercare l’esistenza di un eventuale _ServiceLocalUtil associato a questo oggetto.

Dopo un po’ ho ripreso il tuo codice in cui fai l’update dell’assetentry e dove tu prendi l’array di tags dal servicecontext ho provato, questa volta con successo, ad assegnare i tags a manella creando a runtime un array di stringhe contenente i tag che qui volevo assegnare.

assetEntryLocalService.updateEntry(
userId, newProduct.getGroupId(),
ASTProduct.class.getName(), product.getPrimaryKey(),
serviceContext.getAssetCategoryIds(), new String[]{"newtag"});

Questa piccolo modifica, seppur sporca, funziona. Adesso ti chiedo se hai qualche percorso più elegante da seguire. Ultima cosa e chiudo. Dopo aver fatto questa piccola modifica, ho aggiunto la tag cloud portlet nella mia pagina. E qui ho trovato tra i tag, anche quello appena creato ed associato alla mia entity. Adesso ciò che vorrei ottenere, ma non ci sono ancora riuscito, è fare in modo che cliccando su quel tag, la mia portlet mostri solo gli elementi taggati, un po’ come fa ad esempio la document library quando si clicca su un tag associato ad uno dei documenti. Probabilmente per ottenere questo risultato, devo lavorare ancora sulle classi XXXAssetRenderer e XXX RenderFactory. A questo punto, stavo confrontando l’esempio che hai messo nel tuo articolo con le rispettive classi nel sorgente della document library e spero di trovare qualcosa di utile. Se hai consigli da darmi, sono sempre ben accetti.

Grazie mille di tutto, Federico.
Inviato il 09/07/15 14.02.
Federico Cerminara
Ciao Jader, man mano che passano i giorni e affondo la testa dentro Liferay capisco gradualmente cose che prima mi erano oscure; il risultato è che i dubbi, le domande, lasciano spazi ad altri dubbi, ad altre domande.

Ho compreso ad esempio molte che portlet già presenti in Liferay siano concepite in maniera da formare un incastro con le nuove che vado a sviluppare. Cioè, tornando ad esempio sul codice che illustri in questo articolo, definendo nella mia portlet le classi legate al renderer, spiego alla portlet AssetPublisher come mostrare i miei contenuti (nelle modalità FULL ed ABSTRACT).

C’è qualche meccanismo simile per cui cliccando su un tag nella portlet TagCloud, spiego alla MIA portlet che deve mostrare gli elementi che hanno quel tag? La mia idea spulciando le pagine view.jsp et similia dell’assetPublisher o della document library portlet è che la lista che vado a passare al result del search container sia ricavata proprio tenendo conto di quei tag (come intuisco anche dal display dei msg key="documents-with-x-x"). Mi chiedo se non ci sia qualche incastro più naturale.

Eventualmente se il tutto passa dalla scrittura di una query (immagino una join tra la mia entità e le tabelle assettag, assetentry e assetentries_assettags) come e dove potrei trovare un esempio di uso di una query? (Intendo qualcosa di più complesso dei finder ad hod definiti nel service.xml) E il risultato delle query può passare mediante la definizione di classi fittizie, e soprattutto non necessariamente legate al problema della persistenza ma solo finalizzate alla visualizzazione? Sto pensando a qualcosa che assomigli al select new it.x.y.myclass(…) di hibernate/jpa…

Se hai, avete qualche dritta da darmi, ne sarò felice. Grazie sempre di tutto, Federico
Inviato il 09/07/15 14.02.
Jader Jed Francia
Ciao Federico!
Scusa la mia latitanza ma sono stato un po' incasinato in questi giorni! emoticon
Allora, per rispondere alla tua domanda riguardo a come passare tag / category da associare al tuo Asset, io utilizzo le taglib apposite che il portale mette a disposizione.
Nel dettaglio, all'interno della JSP, uso queste taglib:

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

// Uso le taglib
<liferay-ui:asset-categories-selector/>
<liferay-ui:asset-tags-selector/>

Queste taglib, magicamente, ti mettono in pagina i widget di Liferay per selezionare categories e tags.

Nella action della portlet che riceve la post, poi, vado ad associarle al mio Asset cosi' (nota che io wrappo questa roba in un metodo della mia LocalServiceImpl in modo che sia sempre presente come logica.. ):

...
assetEntryLocalService.updateEntry(
progetto.getUserId(), progetto.getGroupId(), Progetto.class.getName(),
progetto.getPrimaryKey(), ctx.getAssetCategoryIds(),
ctx.getAssetTagNames());
...

Come puoi vedere ci pensa il ServiceContext a passare i parametri corretti all'AssetFramework, perche' le taglib che abbiamo usato sono progettate per "dialogare" direttamente con il ServiceContext.

E con questo dovrei aver risposto alla domanda che mi hai fatto sulle tag / categories.

Per l'altra domanda ti rispondo nella domanda che poni qui sotto! ;)
Inviato il 09/07/15 14.02 in risposta a Federico Cerminara.
Jader Jed Francia
La risposta alla domanda che poni, ovvero "come faccio a prendere fuori solo i miei Asset che rispondono a determinati tag / categories" richiede una spiegazione un po' piu' articolata rispetto alla risposta precedente che ti ho dato! ;)
È il caso che ci scriviamo sopra un bel post per il blog; quindi chiederò ad un mio collega di farlo così da poterti rispondere in maniera più approfondita! emoticon

Ti mando una mail appena l'abbiamo scritto! emoticon

A presto, ciao, J.

UPDATE: abbiamo scritto il post da qualche giorno; allego qui il link per comodità di chi legge:
http://blog.d-vel.com/web/blog/home/-/blogs/estrarre-asset-utilizzando-tags-e-categorie-in-liferay-6

Ciao, J.
Inviato il 09/07/15 14.02 in risposta a Federico Cerminara.
Michele Michele Tarantino
Ciao
sto avendo un problema con la pubblicazione di una entity custom in asset publisher in liferay 6.2.
Mi spiego meglio : faccio tutto quello che che mi si dice sopra verifica nel db e lo scrive ma continuo a nn vederla.
In liferay 6.1.1 funziona benissimo.
qualcosa è cambuiato nelle 6.2?
Qualcuno può aiutarmi è urgente
grazie
Michele
Inviato il 09/07/15 14.02.
Jader Jed Francia
Ciao Michele!
Non ho capito il problema!
Sulla 6.2 -CE o EE?- inserisci una entity come asset ma non la vedi nell'asset publisher? E' cosi'?
Sei sicuro di aggiungere la tua entity sia nelle resource che negli asset?

Fammi sapere, ciao, J.
Inviato il 09/07/15 14.02 in risposta a Michele Michele Tarantino.
Michele Michele Tarantino
Ciao
La versione è la 6.2 -CE
Ho verificato in assetentry e resourceaction e trovo le miei entity.
Dove sto sbagliando?
Grazie
Michele
Inviato il 09/07/15 14.02 in risposta a Jader Jed Francia.
Jader Jed Francia
Guarda, per le info che mi stai dando non riesco a dirti "dove" o "cosa" sbagli.
Hai modo di passarmi la portlet che hai fatto, così da poter guardarla e capire che cosa si rompe?
Fammi sapere, grazie, ciao, J.
Inviato il 09/07/15 14.02 in risposta a Michele Michele Tarantino.
Michele Michele Tarantino
Come faccio a passarti la portlet?

Michele
Inviato il 09/07/15 14.02 in risposta a Jader Jed Francia.
Jader Jed Francia
Manda via mail!
jfrancia at d meno vel punto com! emoticon
Ciao!
Inviato il 09/07/15 14.02 in risposta a Michele Michele Tarantino.
Michele Michele Tarantino
Ciao caro
hai avuto modo di controllare la portlet che ti ho inviato
sto impazzando potresti aiutarmi a capire dove sta il problema
grazie
Inviato il 09/07/15 14.02 in risposta a Jader Jed Francia.
Jader Jed Francia
Ciao Michele!
Ho visto il codice che mi hai inviato e mi sembra che in effetti tu abbia fatto tutto bene!
Non ho ancora avuto modo di testare quello che hai fatto ma a livello di codice quello che vedo e' tutto corretto.
Tu dici che inserendo record in tabella poi l'asset publisher non vede il tuo asset e quindi non riesce a fartelo selezionare?
Comunque a me non risulta ci siano stati cambiamenti nella 6.2 per la parte di asset e risorse; questa mattina chiedo consiglio anche ai colleghi e ti faccio sapere: scusa per questo delay ma sono giorni pieni.. Spero capirai!
Ciao, J.
Inviato il 09/07/15 14.02 in risposta a Michele Michele Tarantino.
Michele Michele Tarantino
Ciao Jader,
grazie per averi risposto . Ti capisco bene figurati.
La risposta alla tua domanda è si
Inserisco un nuovo asset e quando ricarico la portlet di asset publisher nn la visualizza nella lista degli assett della portlet.
Grazie mille
aspetto tue notizie
Michele
Inviato il 09/07/15 14.02 in risposta a Jader Jed Francia.
Jader Jed Francia
Ok; ho capito cosa intendi.
Oggi pomeriggio prototipo un portlettino che fa questa cosa su LR62 e vedo se a me si riproduce il problema; se mi funziona poi te lo giro, cosi' fai il check al contrario: che ne dici??

Fammi sapere, ciao, J.
Inviato il 09/07/15 14.02 in risposta a Michele Michele Tarantino.
Michele Michele Tarantino
ok proviamo :-)
Michele
Inviato il 09/07/15 14.02 in risposta a Jader Jed Francia.
Jader Jed Francia
Ciao Michele!
Ho fatto la prova e funziona tutto come mi aspettavo anche sulla 6.2!
Ti mando in mail la *LocalServiceImpl cosi' che tu possa vedere il codice che da me "gira"! emoticon
Fammi sapere se hai ancora problemi! emoticon

Ciao!
Inviato il 09/07/15 14.02 in risposta a Michele Michele Tarantino.
Viviana Piatti
Ciao Jader,

sto seguendo la tua guida per utilizzare l'Asset Publisher con alcune entity custom.
Per fare alcune prove, ho seguito il post MokaByte 161 di Valeria Amato per creare delle entity custom attraverso il ServiceBuilder (Gestione Libreria).
Sto utilizzando la versione 6.2 di Liferay.
Purtroppo però, configurando l'Asset Publisher in modalità "Manual" e scegliendo l'Asset Type corrispondente alla mia entity custom, Liferay va in OutOfMemory.

Credo che il problema stia a livello di Search. Infatti, pur non avendo Autori nel database, la search (invocata dalla AssetEntryLocalServiceUtil) ritorna 18 risultati che nulla hanno a che fare con la entity Autore.

Mi sembra di aver seguito correttamente la tua guida, hai dei suggerimenti a riguardo?

Grazie in anticipo!
Viviana
Inviato il 09/07/15 14.02.
Jader Jed Francia
Ciao Viviana!
Quello che posso dirti, che poi era anche il problema che segnalava Michele nei post precedenti al tuo, è che nella 6.2 l'asset publisher utilizza sempre l'indice per estrarre gli oggetti da mostrare. Questo significa sostanzialmente due cose:
- che devi sempre implementare l'indexer
- che devo fare un post d'aggiornamento a questo! emoticon

Tu hai implementato l'indexer sui tuoi oggetti?
Se mi dai qualche dettaglio in più sull'implementazione vediamo come riesco ad aiutarti! emoticon

A presto, ciao, J.

P.S. L'articolo di MokaByte è stato scritto da Lorenza Amato, non da Valeria! emoticon
Inviato il 09/07/15 14.02 in risposta a Viviana Piatti.
Viviana Piatti
Ciao Jader,
grazie per la tua risposta, è stata utilissima!
Effettivamente mancava la classe Indexer :-)
Ora riusciamo finalmente a selezionare gli asset custom dall'asset publisher!

A presto, ciao,
Viviana
Inviato il 09/07/15 14.02 in risposta a Jader Jed Francia.
Jader Jed Francia
Ottimo! ;)
Sono contento d'esservi stato d'aiuto!

Se vi occorre altro mi / ci trovate qui! emoticon
Ciao!
Inviato il 09/07/15 14.02 in risposta a Viviana Piatti.