Personal tools

video

Aug 09, 2012

Integrazione continua del codice JavaScript in Plone con Buster.js

Filed Under:

L'importanza di rilasciare codice JavaScript testato su più piattaforme è una priorità per molte applicazioni web. In questo post vi parlerò di uno strumento che facilita l'esecuzione di test unitari non assistiti su codice JavaScript.

Oggi come oggi uno sviluppatore di siti web deve tenere conto del fatto che il risultato del proprio lavoro, nella stragrande maggioranza dei casi, verrà fruito usando dispositivi dalle caratteristiche più svariate.

Capita sempre più spesso che le richieste del cliente convergano nel richiedere un sito con un design responsivo, fruibile tanto sul touchscreen di un telefonino quanto sul ben più ampio schermo di una postazione desktop, veloce e performante sia su rete mobile che su rete fissa.

Sfruttare al massimo le potenzialità offerte da JavaScript è ormai diventato un imperativo categorico per soddisfare queste richieste, tanto è vero che oramai si parla di applicazioni JavaScript.

Per raggiungere l'obiettivo è necessario scrivere codice ottimizzato e a prova di browser. Chi lavora nell'ambiente non può non accorgersi dell'enorme progresso a cui si è assistito negli ultimi anni e del fermento tutt'ora in atto.

Ovviamente Plone, che da sempre è "sul pezzo", sta seguendo questa strada, aumentando sempre più le funzionalità che si appoggiano su questo linguaggio.

read more

May 10, 2012

La webtv del Comune di San Lazzaro

San Lazzaro Web TV

La webtv del Comune di San Lazzaro

Filed Under:

Un progetto multimediale che ha "in Comune" (a San Lazzaro di Savena, Bologna) con Plone solo il codice (python) e le tastiere che ci hanno lavorato (le nostre)

San Lazzaro webtvE' online la nuovissima piattaforma multimediale

del Comune di San Lazzaro di Savena destinata a potenziare la presenza sul web di un Ente da tempo attento alla comunicazione e alla diffusione delle proprie attività.

Sanlazzarotv.it, infatti, si affianca al portale Mediateca per offrire una miglior integrazione tra i contenuti audio e video prodotti dalle proprie strutture e spesso dispersi su diversi canali quali YouTube, Vimeo e Blip.tv.

"Una webtv per raccontare il Comune e il nostro territorio, per costruire un’identità della comunità stessa" - Ufficio Stampa del Comune di San Lazzaro di Savena

 

 

 

read more

Nov 10, 2011

PloneConference 2011: novità e conferme

Di ritorno da San Francisco, ecco le anticipazioni e le conferme di cui abbiamo discusso durante una delle ultime best conference ever

Ancora una volta: "the best conference... ever" (cit.)
Tre track parallele, numerosi openspace, meeting in e out la conference, social party(!) ogni sera e per finire l'usuale sprint

Le 3D, ma molto altro

Il leitmotif di quest'anno è stato senz'altro il tris di Diazo, Deco e Dexterity. E' già un po' di tempo che se ne parla e non vi nascondo un po' di delusione nel vedere che sono ancora temi importanti.

Il punto cruciale sta nel fatto che negli anni passati è stata tentata una rivoluzione, che avrebbe però avuto un impatto troppo importante su tutto l'ecosistema Plone. Questo ha portato a una serie di complicazioni e di refactoring.

Ora si sta ragionando in termini di add-on per Plone che ne migliorino l'esperienza, senza introdurre stravolgimenti.

Diazo & CMSUI

E' ormai un sistema maturo utilizzato in produzione da molto tempo.

L'idea è di:

  1. semplificare la fase di skinning di Plone limitandola al frontend, più facilmente gestibile da Diazo,
  2. demandare a CMSUI tutta la fase di gestione del backend mantenendo il tutto contestuale, ma indipendente dal layout.

Direi che questi due video da soli sono sufficientemente esplicativi.

Diazo Theme Manager:

CMSUI:

Deco

Sta raggiungendo anche lui la maturazione e si sta lavorando sulla user experience. L'idea in questo caso è quella di sostituire prodotti come PortletPage

o Collage. Questa una preview realizzata dai colleghi di FourDigits.

Dexterity

Sugli scudi infine anche Dexterity, di cui parlammo ancora due anni fa come promessa e che ora sta raggiungendo il suo compimento. Sull'interfaccia c'è ancora da lavorare e non è uno strumento per tutte le stagioni, ma è sicuramente estremamente interessante.

Gli altri temi caldi

I miei talk preferiti sono stati:

  • Clone to Plone
  • Multiplayer Plone
  • Make plone search work like Google

Il primo racconta l'utilizzo di FunnelWeb per migrare portali da un altro sistema a Plone.

Nota mentale: ogni migrazione è un'isola, ogni migrazione è "painful"

Il secondo è stato tenuto da Geir Baekholt su istigazione di Yiorgis Gozadinos e permette di utilizzare Plone un po' alla GoogleDocs con tanto di chat e status:

 

Infine l'uso di Solr al fine di ottimizzare gli indici permette anche di aumentare le funzionalità "googlesche" di Plone:

 

Pyramid

La track "Related Tech" è stata fortemente monopolizzata da Pyramid. E' la tecnologia "sorella" di Plone che abbiamo sposato da tempo. Ne abbiamo parlato qui, qui e anche qui. Senza contare il talk di Andrew che ormai è un bestseller alle varie conferenze.

Pyramid è in diretta concorrenza con Django (framework di cui viceversa non si è parlato). E' da sottolineare il fatto che praticamente tutti i Plonisti a S. Francisco avessero fatto la stessa scelta e questo ci conforta sapendo di aver scelto a suo tempo nel modo corretto, ma soprattutto di essere in buona compagnia.

Il Keynote

Quest'anno l'usuale keynote è stato tenuto da P.J. Onori. Personalmente l'ho trovato di particolare ispirazione: è un inno alla crescita professionale, al capire l'usabilità delle cose, alla condivisione di esperienze tra developer e designer.

Più volte mi sono ritrovato a dire "si! si! si!".

 

I nostri talk

Avrete modo di leggere di più nei prossimi giorni sui talk (e lighting talk) di Andrew e Stefano. Mi limito a segnalarvi le presentazioni:
  • Bootstrap your app in 45 seconds (slideshare)
  • Plone in the Public Sector: Business and Sustainability Models (slideshare)

Apr 24, 2010

Cool as Cooliris

Come inserire una galleria fotografica in Plone dalla spiaggia sorseggiando un drink

Cooliris ti permette di ottenere info da una risorsa multimediale web e di creare da queste una galleria fotografica estremamente attraente. Cooliris è stato pensato per le fonti più famose (flickr, youtube, picasa e facebook). In generale però ti permette di utilizzare un media rss generico.

Non è un tool plone, non è fortemente integrato, è tutto bellamente esterno. Se ne occupa qualcun altro a farlo funzionare. ahhh, relax.

 

Ma perchè ci interessa in ambito Plone?

Plone può essere utilizzato come portale, come blog, come intranet ecc. chiaramente inserire una galleria Cooliris vien comodo.

Questo blog è ovviamente realizzato in plone (what else? :) ed è stato banale inserire la gallery qui sopra. Ho semplicemente utilizzato il sistema Express di Cooliris e generato quello che loro chiamano "wall". Poi l'ho incluso in questo post.

D'altro canto, Plone è anche un generatore di contenuti.

Tutti sappiamo che possiamo inserire immagini in un portale plone, ma anche inserirle all'interno di una news o anche creare tipi ad-hoc che le prevedano.

Chiaramente anche eventuali video possono essere gestiti, così come (ad esempio se si utilizza redturtle.video) ottenere riferimenti a contenuti che sono su youtube.

Vien facile quindi pensare che, con un po' di programmazione, si possa dire a plone di generare, magari a partire da una collezione, un media rss che cooliris possa lavorare per noi. Un po' come si fa per il classico rss della collezione stessa.

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
      <rss version="2.0" xmlns:media="http://search.yahoo.com/mrss/"
      xmlns:atom="http://www.w3.org/2005/Atom">
      <channel>
          <item>
               <title>Picture A</title>
               <media:description> This one's my favorite.</media:description>
               <link>pl_images/A.jpg</link>
               <media:thumbnail url="http://example.com/pl_thumbs/A.jpg"/>
               <media:content url="http://example.com/pl_images/A.jpg"/>
          </item>
          <item>
              <title>Video B</title>
              <link>http://example.com/pl_images/B.jpg</link>
              <media:thumbnail url="http://example.com/pl_thumbs/B.jpg"/>
              <media:content type="video/x-flv"
              url="http://example.com/pl_images/B.flv"/>
          </item>
      </channel>
      </rss>

 

In questo modo puoi:

  • avere contenuti "social" aggregati in qualche modo sul tuo portale
  • avere contenuti del tuo portale che diventano "social" via i media rss
  • avere i tuoi contenuti in una gallery "cool" nel tuo stesso portale (o in altri che tu stesso gestisci)

In aggiunta al servizio Express hai anche a disposizione un po' di API (se non hai delle API non sei nessuno :) e scegliere se utilzzare javascript o flash per realizzare la tua gallery. Chiaramente non è un lavoro per comuni mortali, serve sempre almeno tuo cugino, quello che sa di internet, o forse magari un bravo professionista :D

Tutto facile, tutto già pronto?

Un buon uomo di marketing ti direbbe: "thatì's all folks! enjoy"

Per vostra fortuna non sono ancora passato al lato oscuro della forza. Mi piace, quindi, ricordarvi che, per un sacco di buone ragioni, il buon Plone non ti permette di inserire tag object all'interno del corpo della pagina.

Niente di devastate comunque, occorre che vi ricordiate di abilitarlo esplicitamente. E il nostro amico Sam Knox ci ricorda come.

Chiaramente questo settaggio farà sì che ogni utente (si tutti, anche quello cui stai pensando e che fa sempre dei danni) abilitato sul vostro portale o blog Plone potrà effettuare questa operazione. Be careful :)

L'altro punto da tenere in considerazione è proprio il fatto che si tratta di un sistema esterno, che non controllo, che ha le sue politiche, che da un giorno all'altro potrebbe variarle.

Ma anche questo è questo il web 2.0, no? Occorre conoscere, pensare e valutare se un tool fa al caso nostro o meno. Una volta fatto, si vive tranquilli.

Mar 22, 2010

Conditional Javascript choices relying on server side configurations

Filed Under:

Have you ever felt the need of make a Javascript choice, executing some client side actions, basic this choice on some server side configuration? Here an interesting way I recently taked, thanks to the powerful jQuery plugins structure.

Describing the problem

I'm near to release a new version of collective.flowplayer_toolbar (so it's only on collective SVN right now).

The first version of the product (see the old blog post about it) give a new Javascript controlsbar to Flowplayer, disabling the native Flash ones.

In a production environment we received some comments about this choice because when disabling the Flash controls you are not able anymore to use fullscreen mode... bad!
The only solution is to keep both control systems because is not possible (due to security issue) to control fullscreen from Javascript.

Have both controls give us the best freedom (features and accessibility)... but to be honest I find it really ugly!

Flowplayer instance with controlsbar

So, the best way is to give some configuration for switch from:

  • using only the Javascript controls
  • using Javascript and Flash controls

The collective.flowplayer choice

The same kind of problem has been overcome by collective.flowplayer.
Some of the configuration you can manage in the flowplayer_properties leave to changes in the client-side Javascript behaviour.

I'm not sure that this is the only motivation, but this problem is solved there providing the Javascript code not using a static file (so not giving a Javascript text source) but using a zope 3 view.
This view (collective.flowplayer.js) return a text/javascript content type:

    def __call__(self, request=None, response=None):
        """ Returns global configuration of the Flowplayer taken from portal_properties """
        self.update()
        self.request.response.setHeader("Content-type", "text/javascript")
        ...

The problem with this approach is that you must work with Javascript code written inside Python string... not really comfortable.

Of course, the problem is only for the developer. Client side the Web browser will not feel any difference.

Experimental approach

As far as Flowplayer works well with jQuery (and jQuery Tools, that is a requirement of collective.flowplayer using plone.app.jquerytools) I'm trying a second approach to the problem. This because:

  • I don't like to write Javascript inside strings
  • I really like the power of jQuery plugins support, and this has become more clear to me after having read recently a book on this.

Following the server side collective.flowplayer approach I added a new property to the portal_properties tool (it's only a single property, so I added it to the same flowplayer_properties sheet).

This boolean property (toolbar_flash_controlsbar) must only controls this single line of Javascript code:

this.getPlugin("controls").hide();

I need a way to execute this only when the flag is True.

The solution is simple: execute this line of code only when a Javascript variable is evaluated true/false:

if (!show_flash_controlsbar)
	this.getPlugin("controls").hide();

Now we only need a way to controls from the server this client variable, but first it's better to provide a default initialization.

As far as this control is executed inside a Flowplayer event, we can add the initialization before or after this piece of code, directly in the flow of page execution (so the order matters not):

var show_flash_controlsbar = false;

So the default is also the default of the toolbar_flash_controlsbar property (False) and we will not see that Flash controls.

Now we really need a way to react to a True value server-side.

The way used here is to include another (minimal) Javascript piece of code, this time after the ones above (so, if included, it must be after the initialization of the show_flash_controlsbar).

show_flash_controlsbar = true;

To keep controls on the inclusion of this we need to put this into a separate Javascript file and include it conditionally after the ones above.

The Generic Setup inclusion take this form:

 <javascript cacheable="True"
             compression="safe"
             cookable="True"
             enabled="True"
             id="++resource++flowplayer_toolbar_js/flash_controlsbar.js"
             insert-after="++resource++flowplayer_toolbar_js/flowplayer.accessible-controls.js"
             expression="portal/portal_properties/flowplayer_properties/toolbar_flash_controlsbar|nothing"
             inline="False"/>

In the expression TAL we check and evaluate the server side property (and for security we also put a |nothing, to prevent all sort of errors if, for example, the property has been deleted).

The portal_javascript tool take care of providing this Javascript script or not, even when the it's merged with other and cached.

Don't you talked of jQuery somewhere above?

The only problem with this approach is the namespace pollution. We must be sure that the name of this variable is not used/taken from other Javascript code somewhere in Plone.

jQuery and its plugins technology help in this, and also help to keep things more clear and ordered.

With the syntax below we can make this definition available only inside the jQuery environment, preventing that non-jQuery Javascript code change/use this variable.

jQuery.show_flash_controlsbar = false;

Note the use of jQuery name, not $ or jq: this is how plugin development guidelines recommend to define and use jQuery object when developing plugins.

In our code we can continue testing the condition in this way:

if (!jq.show_flash_controlsbar)
	this.getPlugin("controls").hide();

This is better than before, but we can make it more robust.

This approach can fails only if another jQuery plugin define and use the same name for an internal variable of function (ok, this is paranoyc); if this become true we can get errors or unexpected results.

The best jQuery way is to define an internal namespace, making this problem more and more difficult to arise.

So finally we define the variable in this way:

jQuery.flowplayer_toolbar = {
	/**
	 * Some other script can put this to true to enable also the native controlsbar plugin
	 * This is the only way to get features like the fullscreen.
	 */
	show_flash_controlsbar: false
};

And we test it like this:

if (!jq.flowplayer_toolbar.show_flash_controlsbar)
	this.getPlugin("controls").hide();

The last benefit of using an internal jQuery namespace is to keep similar variables or function together. May be that some other variables (or global functions?) can be needed in future version of this product, so we can add them inside the same namespace.

Going back: is this approach better or not?

Aswer: I don't know. This works well with browser cache but as you can see it needs some more work than providing a dynamic Javascript source from the server using a view.

The most annoying things is the registration of an additional entry inside the portal_javascript tool only for put an additional line of Javascript code... this is not a problem for one script, but can you imagine this repeated for all collective.flowplayer configuration (or for other products too)?
The numbers of entries will explode!