Restrizioni/svantaggi dello sviluppo di portlet per Liferay

Question

Sto considerando lo sviluppo di un'applicazione come portlet da integrare nel portale Liferay. Ci sono significativi svantaggi o limitazioni nello sviluppo di un'applicazione di questo tipo, al contrario dello sviluppo di una normale applicazione web utilizzando il framework Spring?

Liferay sembra richiedere che tutto il contenuto venga aggiunto come portlet. Un'altra opzione su cui riflettere è utilizzare Liferay solo per alcune parti dell'applicazione e aggiungere collegamenti esterni ad altri contenuti sviluppati autonomamente, sviluppati come una normale applicazione web. Ciò, tuttavia, creerebbe la necessità di più meccanismi di autenticazione utente e di una sorta di autenticazione cross-site tra Liferay e l'altra applicazione web.

Qual è il modo migliore per andare?

Answer 1

(Disclaimer: io sono uno degli sviluppatori di Liferay)

Credo che entrambe le opzioni sono buone a seconda delle esigenze. Se hai esperienza precedente nello sviluppo di applicazioni web standalone ma non hai esperienza nello sviluppo di portlet, la selezione del primo ti consentirà di iniziare più velocemente. Gli svantaggi sarebbero che dovresti implementare il tuo sistema di utenti e permessi e non saresti in grado di sfruttare i servizi di portale forniti da Liferay. Se si decide di utilizzare questa alternativa, si noti che è possibile distribuire file WAR regolari su Liferay e verrà automaticamente creato un portlet semplice che utilizza un iframe per mostrare la propria app. Questo ti permetterà di mettere l'app standalone insieme ai portlet nelle pagine di Liferay.

Lo sviluppo di un portlet per Liferay inizia a dare i suoi frutti quando si inizia a sfruttare i servizi del portale che fornisce. Per cominciare, sviluppando un portlet, è possibile dimenticare lo sviluppo del proprio sistema utente e utilizzare quello fornito da Liferay (che è piuttosto potente). Puoi anche utilizzare altri servizi come autorizzazioni, commenti, tagging, categorizzazione, data scoping, ecc. Che ti permetteranno di sviluppare un'applicazione abbastanza completa in un tempo più breve. Lo svantaggio è che la prima volta che lo fai dovrai imparare molte cose nuove, ma la seconda volta andrai molto più veloce.

Spero che questo aiuti.

Answer 2

Ho sempre pensato che Portali come Liferay dovrebbero essere considerati come un'infrastruttura condivisa. Forniscono un modo comune per accedere a applicazioni, servizi condivisi (ad esempio l'autenticazione) e un modo standard di implementazione, ma a scapito delle prestazioni.

Se si intende implementare più di questa applicazione nel Portale, sì, è probabilmente appropriato in quanto si otterranno risparmi in termini di tempo/costi dal non dover sviluppare quei servizi condivisi una seconda volta. E le applicazioni successive appariranno e si comportano in modo simile a questo.

Tuttavia, se questa è l'unica app da distribuire, il sovraccarico del portale non ne vale la pena e si sta meglio andando con una normale applicazione web.

Answer 3

Liferay ha funzionalità CMS e può essere integrato con piattaforme CMS esterne come Alfresco.

Answer 4

Utilizzo Liferay da circa 2 anni per un'applicazione interna. Abbiamo avuto la stessa discussione molte volte durante il ciclo di sviluppo prima della nostra prima versione. Abbiamo dovuto combattere Liferay un paio di volte, a volte a causa della nostra mancanza di conoscenza, a volte a causa dell'ambiente portlet, e occasionalmente a causa di Liferay.

Se si desiderano le opzioni di layout per più applicazioni che è possibile ottenere da un portale, è consigliabile utilizzare Liferay. Se stai scrivendo una singola applicazione, probabilmente non userò Liferay.Penso che un ibrido di alcuni Liferay e alcuni non sia di gran lunga l'opzione peggiore.

Probabilmente non stiamo sfruttando pienamente Liferay, ma se questa è la tua prima app Liferay, è probabile che non lo farai neanche a causa della curva di apprendimento. Originariamente speravamo di avere molti portlet diversi per i diversi aspetti della nostra applicazione, ma a causa della mancanza di buoni meccanismi di comunicazione tra portlet durante lo sviluppo (pre JSR-286) abbiamo finito per scrivere una singola applicazione. Ora che siamo finiti su quella barca, vorrei che non ci fossimo andati senza Liferay, dal momento che tutto quello che stiamo usando è alcune funzionalità di gestione degli utenti.

Usiamo JSF e facelets (entrambe le nuove tecnologie per noi, quindi il dolore potrebbe essere stato autoincluso) e mentre ci siamo migliorati, sembra che ci fossero alcuni cerchi che dovevamo saltare per ordine per farlo funzionare correttamente in un portlet; Cose che non avrebbero dovuto succedere in un normale ambiente di app web. Per molti framework, sembra che il supporto del portlet sia un ripensamento. Questo ovviamente non è specifico di Liferay, è solo un sottoprodotto di lavorare all'interno dell'ambiente del portlet.

In una webapp che utilizza Spring MVC, Struts, Faces, Wicket, qualunque cosa, avrai molto più controllo su tutto, ma sarai anche responsabile dell'implementazione di più cose.

In un portlet, si sarà soggetti ai termini di JSR-168 e/o JSR-286. Il portale portal fornirà alcune funzionalità per te, come l'autenticazione dell'utente, ma IMO, un intero portale per l'autenticazione dell'utente è troppo pesante. Vedo la potenza del portale che consente all'utente di personalizzare la visualizzazione di più applicazioni, non presentando una singola applicazione.

È necessario esaminare le specifiche relative al portlet e verificare se soddisfano le proprie esigenze.

http://developers.sun.com/portalserver/reference/techart/jsr168/

Answer 5

Liferay e portlet, in generale, sono grandi per una classe molto particolare di applicazioni. Se lavori per un dipartimento IT e devi combinare app per o da più reparti, i portlet sono la soluzione giusta. In teoria puoi inserire portlet da diversi distributori e tutti vivranno in armonia all'interno dello stesso ambiente.

Tuttavia, se si sta creando una domanda che è uno dei seguenti

1) creato interamente da un unico team 2) ha un unico fornitore per le esigenze 3) ha esigenze che non sono un sottoinsieme delle funzioni disponibili nel contenitore del portlet. 4) ha un designer grafico che non è disposto a vivere entro i confini delle applicazioni di stile del portale.

quindi attaccare con qualcosa come la primavera sarebbe la strada da percorrere.

Spring ei suoi numerosi sottoprogetti forniscono molti servizi e infrastrutture condivisi offerti dai portlet, ma sono offerti in modo aperto e più flessibile. Puoi scegliere e scegliere quello che vuoi.

I portlet apportano molte delle decisioni di progettazione in termini di autenticazione e autorizzazione, navigazione e layout. Se i piani che hai per la tua applicazione cadono al di fuori di quelle decisioni, passerai molto tempo a creare soluzioni alternative per cercare di ottenere ciò che vuoi.

Answer 6

Liferay è un sistema estremamente potente, ci sono molti servizi e applicazioni disponibili già pronti ma il più grande svantaggio è la mancanza di documentazione. È impossibile sapere tutto solo guardando il codice, quindi secondo me se non hai l'esperienza non andare per Liferay.

Answer 7

Uomo, controlla questa soluzione plug-in Netbeans IDE + PoralPack3.0 + bundle Liferay 5.2. Il Portal Pack qui ti aiuta fornendo un bel editor GUI per il file service.xml dove puoi definire le entità o le strutture del database e dalla stessa GUI puoi generare il codice dei servizi che può essere usato all'interno del tuo portlet.

Per maggiori informazioni controllare il link qui sotto data: http://www.liferay.com/web/satyaranjan/blog/-/blogs/portal-pack-:-write-database-portlet-using-service-builder-plug-in

Answer 8

Tutti, si prega di non prendere questo come traina/fiammeggiante. Questo è qualcosa che sento che la comunità di Liferay dovrebbe affrontare e tutti quelli che pensano di usare Liferay dovrebbero saperlo.

Svantaggio: nessuna documentazione. Nulla nemmeno lontanamente, ad esempio, la documentazione di Hibernate. Solo un javadock vuoto (nessun commento nel codice), alcuni hanno risposto a domande nei forum e libri per vecchie versioni (inutili).