bloggers bloggers

Marco Napolitano
Messaggi: 79
Stelle: 0
Data: 17/02/22
Jader Jed Francia
Messaggi: 63
Stelle: 0
Data: 18/02/21
Paolo Gambetti
Messaggi: 2
Stelle: 0
Data: 11/11/19
Katia Pazzi
Messaggi: 1
Stelle: 0
Data: 27/06/19
Ezio Lombardi
Messaggi: 11
Stelle: 0
Data: 10/04/18
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
Indietro

Convenzioni nello sviluppo all'interno di Liferay Portal

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:

Struttura di progetto Liferay Portlet all'interno di 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 {
...


Precedente
Commenti
Nessun commento. Vuoi essere il primo.