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.

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!

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!

First of all: some terms

After finishing this article I understand that people not familiar with this argument and software can be confused, so:

• Flowplayer (in capitalized form) is a Flash player for audio/video files, indipendent from the Plone technology.
• collective.flowplayer is a Plone products that use Flowplayer and give this player well integrated in Plone CMS
  
• collective.flowplayer 1.x is an old release family, that use Flowplayer 2.x
• collective.flowplayer 3.x is the last release family, that use Flowplayer 3
  

Introduction to main characters

Flowplayer is one of the most promising Flash audio/video player available right now, and we can use it in a simple way inside Plone site thanks the collective.flowplayer, a well know product that replaced the use of p4a.video in recent Plone experiences.

Flowplayer is good, and open source, but not the most accessible available player. Our work with collective.flowplayer accessibility begin when the available release was the 1.0.x version.

As noted above, Flowplayer version used in this old release was the old 2.x, so many of the most recent and cool features were missing; on the other hand, the current 3.x family is heavily integrated with jQuery Javascript framework.
Not less important, the Flowplayer team is the one who released the jQuery Tools, the javascript addon for jQuery recently integrated in Plone 4 thanks to plone.app.jquery.

Fixing collective.flowplayer 1.x

The main accessibility problem of Flowplayer is its flash controlbar. Practical tests show that is not easy to handle video controls using the keyboard.

Our customer, the same that ask for accessible videos in Plone and also like Flowplayer very much, provide us a static HTML example of Flowplayer that use Javascript controlbar, simply usable with keyboard. The problem was that this example supports Flowplayer 3.2, the current version of the Flash player, but not the version used in the Plone addon.
Also the example provide a patched version of the controlbar plugin for Flowplayer. This custom version add some missing HTML attributes and WAI-ARIA support.

After looking on the web we found that even if Flowplayer 2 was backward compared to the new branch, it provides some limited APIs, usable through Javascript.

Our target was to replicate all the feature seen in the Flowplayer 3 demo in the Flowplayer 2 environment... of course this was not so easy! However after some work we find a way to provide those features:

• a play/pause button
• a stop button (not required, but was simple to do)
• a timer display

The only feature "impossible" to obtain (directly) was the progressbar... to be honest, some additional Javascript could also realize this (we have the duration of the video, we have the current execution time, we know how to perform arithmetic division... why not draw ourself? :-) but was enough.

What we really don't like was this: we found no (simple) way to write a Plone addon that work with collective.flowplayer 1.0, adding to it our new features.

We don't waste more time: we made a branch of the original collective.flowplayer 1.x, providing our new feature.

Thank you! Thank you! We have collective.flowplayer 3.x!

After a few weeks collective.flowplayer 3.x was released (I think that the developers team skipped the 2.x version for aligning the Plone product's version to the Flowplayer one).
So we came back to the original example give to us (the customer project was happy finished using our branch) just for test the new feature available and to understand is in future a new, better approach is possible.

The API's of the latest Flowplayer versions are more complete and powerful, heavily filled with the jQuery power.

This time we were able to develop something that could live and enhance the original collective.flowplayer, releasing only a new product: collective.flowplayer_toolbar.

The final result really better than the old approach; without embarrassment I can say that we did a few line of codes! The most part of the work of our new controlbar came from Flowplayer features and one more time from the great jQuery library.

You want see the "core" of this product?

/**
 * Javascript code for adding accessible toolbar to flowplayer players in the page 
 */

jq(document).ready(function(event) {
	$f("*").each(function() {
		this.onLoad(function(event) {
			this.getPlugin("controls").hide();
			var p = jq(this.getParent());
			var p_width = p.width();
			var time_width = (p_width<400?99:129);
			var hulu_id = "hulu-"+ (jq(".hulu").length+1);
			p.after('<div id="'+hulu_id+'" style="width:'+p_width+'px" class="hulu">\n'
				+'<a class="play" href="javascript:;" role="button">Play</a>\n'
				+'<div class="track" style="width:'+(p_width-46-46-time_width)+'px">\n'
				+'    <div class="buffer"></div>\n'
				+'    <div class="progress"></div>\n'
				+'    <div class="playhead"></div>\n'
				+'</div>\n'
				+'<div class="time" style="width:'+time_width+'px"></div>\n'
				+'<a class="mute" href="javascript:;" role="button">Mute</a>\n'
				+'</div>\n');
			this.controls(hulu_id);
			// Now I'll fix all other positions of the new toolbar
			jq("#"+hulu_id+" a.mute").css('left', p_width-46);
			jq("#"+hulu_id+" div.time").css('left', p_width-46-time_width);
		});
	});
});

The rest of the egg simply use a limited version of the original CSS of the demo page in Flowplayer site, the patched controlbar plugin (but you can use the original one without problems)... nothing more!

The jQuery presence make real the injection our new feature on existings Flowplayer instance in the page (for example, this is also working properly for our redturtle.video product). No need to patch/branch collective.flowplayer, also no need to override some views or resource of it.

Conclusion

This work can be also a proof-of-concept for future Flowplayer integration with additional features. The player supports many additional plugins (Yuri point my attention to the Caption Flash plugin...).

I talk presentati sono stati 2:

1. Carneade, dar vita alle relazioni del mondo reale: Plone come gestore di organizzazioni
2. collective.amberjack: Plone come piattaforma per i tutorial

Tutto il materiale è già in linea.

Carneade

• La presentazione (su slideshare)
  
• un video di presentazione del sistema (su youtube)
• l'intero talk in streaming video (su ustream)

collective.amberjack

• La presentazione (su slideshare)
• un video di presentazione del sistema (su youtube)
• l'intero talk in streaming video (su ustream)
  

A new version of redturtle.video was released on pypi:

http://pypi.python.org/pypi/redturtle.video/0.2.0beta

The package redturtle.video is a video support for Plone, based on collective.flowplayer.
In the new version of redturle.video two new fields are added to content types Video files and Video link. These new fields are "Year" and "Duration".

The information on the lenght of video is achieved through the use of packages: 'hachoir_core', 'hachoir_metadata' and 'hachoir_parser'.

The "Video Gallery" portlet shows content image fields taken from videos. In the new version "Video Gallery" portlet shows also the new informations on the year and duration of the video and also the title of the video.