Il progetto

RedTurtle Technology, in partnership con Mimulus, ha realizzato il portale globale corporate che Aeterna Water, una multinazionale del settore Acqua, utilizza a supporto della promozione, commercializzazione e assistenza di impianti di conservazione e distribuzione dell’acqua e derivati per consumo individuale. Il portale comprende la gestione di servizi tra cui  e-commerce e sales force automation.

La tecnologia

Il sistema, basato sulla integrazione profonda tra il framework Pyramid (destinato alle logiche applicative) e il CMS Plone (destinato al front-end Web), e appropriatamente denominato CUP, acronimo di Corporate Unified Platform, spicca non solo per la poliedricità ed il livello di integrazione con il mondo mobile, non escluso un dialogo diretto con i dispositivi di distribuzione acqua (connessi con il sistema via SMS), ma anche per la complessità dei flussi di lavoro implementati nella varie aree, workflow che risultano fortemente personalizzati sulla base delle specifiche fornite dal committente, che ha investito in una completissima analisi funzionale preliminare, che ha agevolato fin dall'inizio un approccio integrato nella realizzazione dei diversi componenti logici e operativi, numerosi dei quali si trovano all'incrocio di differenti workflow, mentre alcuni sono contraddistinti da una forte componente algoritmica.

Un ERP di nuovo genere

Il sistema, che si appoggia al DB libero Postgres, è anche la Intranet su cui il Cliente gestisce le forniture e il magazzino, e costituisce quindi una sorta di ERP con front-end Web, emulando numerose delle prestazioni tipiche dei gestionali di altissima gamma, con l'aggiunta di funzionalità tipiche dei portali Corporate.

Questa sua doppia natura, assieme all'articolazione dei workflow, ha reso necessaria una gestione particolarmente sofisticata di utenti e gruppi, che tenga conto di un utilizzo multilivello, dal C-level (CEO – CFO – COO – CTO – CMO) ai Clienti e addetti di magazzino, senza escludere la forza vendita ed i fornitori.

Obiettivo principale: supportare un'azienda ambiziosa e moderna, completamente delocalizzata e priva di uffici e sedi fisiche, garantendo al contempo lo stesso livello di sicurezza e di servizio offerto dai competitors.

Questi gli ambiziosi requisiti del progetto, che ha consentito di tradurre in realtà un modello di business che non prevede grandi sedi Corporate né sedi amministrative.

Catalogo delle funzionalità

Gli strumenti e servizi disponibili (per ragioni di spazio la lista omette alcune voci) comprendono:

• Extranet Cliente:
• Anagrafica Clienti
• Stato / inserimento ordini
• Stato / gestione pagamenti
• Chiamate di emergenza, Accesso al supporto tecnico
• Risorse Cliente (FAQ, formulari di reclamo o di customer satisfaction)
• Previsione di profitto
• “Water footprint counter” (monitorizza il risparmio energetico realizzato dal Cliente

• Strumenti Intranet
• Messaggistica interna
• Calendario
• Indirizzario
• CMS
• Forum

• Gestione inventario
• Creazione catalogo
• Gestione magazzino
• Stock trends
• Logistic track
• Limiti di autorizzazione
• Statistiche macchina

• Sales Force Automation
• Gestione rete vendita (leads, trends, revenue)
• Configuratore di macchina

• Piattaforma Ecommerce
• Fatturazione, Controllo pagamenti
• Export dati finanziari
• Shopping online

• Gestione contenuti Web (navigazione per tag, SEO friendly)
• Creazione pagine, Multimedia Gallery
• RSS
• Formulari online

• Knowledge Management (Forum, FAQ, Repository documentale)

• Marketing Automation
• Corporate identity manuals
• Download strumenti di comunicazione
• Email marketing
• Target and transformation page
• Gestione Campagne

Un modello destinato a ripetersi

Il modello concettuale dietro a CUP è generalizzabile a tutte quelle realtà che non gestiscono in proprio il processo produttivo e che pongono l'enfasi sulla delocalizzazione: pare quindi sicuro che in tempi brevi RedTurtle affronterà nuove sfide nello stesso settore.

What we have is a working version of a traversal CRUD. General concept is similar to Sergey Volobuev Kelpie. Everything is based on repoze.bfg 1.2 (though it should work smoothly on 1.3).

Model definition is done using SQLAlchemy declarative approach.  This choice provoke us to use  FormAlchemy as a form generator (with fa.jquery widget support). It's easy to start with but difficult to extend later.  That's why it's the first thing we would like to change in the future.  Everything is glued together with bfg hybrid traversal approach. 

What we are planing to do (probably not exactly in that order):

• check if somebody else didn't start similar project and maybe share concepts or do it together
• check possibility of integrate existing solutions with Pyramid
• reuse what can be reused from our bfg crud and move it to Pyramid
• organize a python sprint that will work on these topics

 

C'è ancora chi crede che un sito Plone si riconosca a prima vista: può essere, se parliamo di installazioni "out of the box" o comunque se si decide di restare nelle skin più classiche. Ma certamente non è un principio generale: la flessibilità di Plone è testimoniata non tanto dalla possibilità di impostazioni grafiche complesse e innovative, quanto dalla sua possibilità di mimetizzarsi completamente in un layout grafico preesistente.

Due casi di studio, entrambi provenienti dall'ambito della Regione Emilia Romagna, dimostrano questa flessibilità con particolare evidenza:

• Nel sito "Io Partecipo" / "Uno x uno", che propone una soluzione mista Plone / non Plone, l'integrazione trasparente di Plone è stata ottenuta grazie a Deliverance (diversi dei nostri tecnici hanno parlato di questa soluzione nelle loro presentazioni: Massimo, Stefano, e nel nostro blog). Deliverance consente di ridistribuire gli elementi grafici di uno o più layout esistenti, assemblandoli in modo differente e - se necessario - armonizzandoli dal punto di vista grafico. Nel caso di "Io partecipo", tutti gli elementi del layout grafico sono riproposti direttamente da un preesistente sito, salvo la colonna di sinistra (notizie, commenti, argomenti) che è invece tratta da un sito plone ad hoc. Ciò ha consentito di mantenere inalterata l'originaria infrastruttura, pur offrendo ai redattori i vantaggi di Plone per la redazione delle informazioni modificate più di frequente.
• Invece, nel caso di Ermes, il portale della Regione Emilia Romagna, gli utenti non si sono accorti di nulla nonostante l'intero portale sia stato interamente reingegnerizzato in Plone. In questo caso, Plone è stato meticolosamente personalizzato in modo molto granulare, per caratterizzare ogni elemento visibile secondo i tematismi grafici e la struttura del portale originale: la buona riuscita dell'operazione può essere testimoniata da chiunque abbia usato Ermes negli ultimi mesi - a parte la differente struttura degli URL, nulla denuncia il cambiamento di tecnologia. Altrettanto rimarchevole il fatto che, sebbene l'originale implementazione fosse in HTML statico e quindi particolarmente leggera, i tempi di caricamento delle pagine in Plone sono immutati: insomma, l'enorme vantaggio di una gestione dei contenuti immediata e "through the web" non si paga in termini di prestazioni. Tra l'altro, a differenza della precedente implementazione statica, il portale Plone sarà agevolmente adattabile ad altri media palmari (ipad/iphone/smartphone in genere).
  

In conclusione, le ragioni per non rinunciare alla veste grafica "storica" di un portale sono molteplici, soprattutto legati all'elevato numero di utenti abituali, e bisogna trasformare questa esigenza in un'opportunità. Il fatto che Plone lo consenta è importante per molti validi motivi:

• dimostra la flessibilità della tecnologia
• abbatte un ostacolo spesso insormontabile: la paura del cambiamento; L'alibi "Ma i nostri utenti sono abituati a vedere le cose in questo modo!" si dissolve con un "E così continueranno a vederle!";
• preserva gli investimenti passati: se il progetto di comunicazione su cui è disegnato il portale è valido, può avere senso mantenerlo anche al variare della tecnologia.

In a Java agent, If you are accessing your document via agentContext.getDocumentContext(), I've found a problem in managing attachment with extractFile method

Error found is "a database handle to a remote database cannot be used by more than one thread"

This is my workaround.

Instead of doing:

AgentContext agentContext = session.getAgentContext();
lotus.domino.Document inDoc = agentContext.getDocumentContext();
Database db = agentContext.getCurrentDatabase();

 try doing this : 

AgentContext agentContext = session.getAgentContext();
lotus.domino.Document inDoc = agentContext.getDocumentContext();
String unid = inDoc.getUniversalID();
inDoc.recycle();
Database db = agentContext.getCurrentDatabase();
lotus.domino.Document inDoc2 = db.getDocumentByUNID( unid );

Now works!

They want tab!

The request is quite common in recent layout that you can see all around the Web. Ok, "portlet" is common, but you can also find many examples of portlets with tabs.

What is this? The data inside portlets is split in sections that you can easily switch with a little Javascript code. The benefit is to put more information inside a tiny space, maybe showing to users only the most interesting ones when he arrive at your page.

Technically speaking this task is so simple that a blog post is not needed... but we don't know what kind of contents we want put inside the portlet tab.

Also the customer want to have the choice of use all (maybe the most part) of Plone portlets available is his installation... We really can't rewrite/overrider all portlets to get this...

...and finally (like everytime) accessibility. Data inside portlets must the accessible and the requirement 15 of the Stanca Act force us to make this available also with Javascript disabled.

Solution

Let's starts from what we can't lose:

• accessibility of the page without Javascript
• all Plone portlet usable as "tab"

For those two reasons the simplest way is to keep Plone portlet engine like it is. Plone portlets are working normally without Javascript, so why don't simply show tabs in only when Javascript is there?

This lead us to a solution. "Simply" generate portlet with tab using Javascript.

One more time again jQuery is our hero. The product add to Plone portal_javascript tool a new jQuery plugin for this. Is not a perfect plugin right now (is a composition of jQuery and normal Javascript OOP) but reach the target.

Here an example:

jq(document).ready(function() {
    var generatedPortlet = jq.tabbedportlet();

    generatedPortlet.makeTab("#portal-column-two .portletNews");
    generatedPortlet.makeTab("#portal-column-two .portletCalendar");
    generatedPortlet.makeTab("#portal-column-two .portlet-static-static");
    jq("#portal-column-two .visualPadding").prepend(generatedPortlet.getPortlet());
});

When page is loaded a new Javascript object is created, and calling makeTab method you can "steal" other existing portlets all around the page (simply giving a jQuery selector, a DOM element or a jQuery object wrapping the portlet).

The method also has other features, look at the pypi page below for more.

Every call to makeTab will remove the portlet and move the DOM elements of the portlet inside a new ones (that, for now, is not inside the document yet).

When you have finished, just put the result of getPortlet method wherever you want.

The final effect is quite good... the demo will show you the page with disabled Javascript, then (long life to Web Developer's Firefox extension) it is enabled again and the page reloaded...

What next?

The product is not so simple to be used by Plone site members (this is not named collective.portlet.tabber... )

A developer or a skinner must provide the additional Javascript inside a product/theme and he must know something about jQuery selectors... but after this starting setup... nothing more!

Another thing Ithat is not perfect is the Javascript structure, not a fully jQuery plugin. You can't fully rely on chaining right now.

More info?

http://pypi.python.org/pypi/collective.portlettabber