Personal tools

eps2010

Jun 04, 2010

Appunti dall'European Plone Symposium 2010

Filed Under:

l'evento

Dal 26 al 27 maggio 2010 si  tenuto, nella bellissima cornice sorrentina, l'European Plone Symposium 2010. L'evento, organizzato da Abstract,  è ormai un appuntamento fisso per la comunità Plone.

Organizzato in contemporanea con il Plone Symposium East 2010 (Pennsylvania, US), l'evento si è aperto con l'intervento di Geir Bækholt di Jarn per fare il punto sulle novità dell'ormai imminente Plone 4. Siamo ormai alla beta 3 e l'enfasi è stata posta sui tanti miglioramenti anche dal punto di vista dell'interfaccia e delle prestazioni.

Lo sforzo degli sviluppatori, anche dei Tune-Up, compreso il 31-esimo TuneUp che si è svolto durante lo sprint di venerdì 28 maggio, è volto a chiudere gli ultimi ticket per poter rilasciare la prima versione stabile di Plone 4.

Plone 4

La versione 4 può essere considerata una versione di transizione, sia per gli sviluppatori che per gli utenti "finali", a Plone 5, dove, si vedrà all'opera Deco, l'innovativo sistema di composizione "a tasselli" dei contenuti.
Inoltre Geir ha parlato già di alcune delle novità che ci aspettano in Plone 4.1:

I Talk

Matt Hamilton

Matt ha rassicurato Rok Garbas sulla presenza a Bristol di spazi per lo skateboard :)

Nel primo intervento, rivolgendosi soprattutto agli integratori, ha discusso di un approccio interessante e forse non così praticato come si potrebbe pensare. L'idea è che quando ci si trova di fronte alla necessità di dover integrare un prodotto con nuove funzionalità si cerca sempre di non alterare il prodotto originale per mantenere la possibilità di aggiornarlo.

Per raggiungere questo obiettivo in alcune situazioni, se il codice del prodotto originale lo consente, è possibile sftuttare gli eventi. L'idea è semplice: basta registrare il codice da eseguire quando si scantena l'evento e il gioco è fatto. Matt ha portato un esempio di plone.app.discussion a cui ha dovuto aggiungere una funzionalità antispam e la modifica fatta a GetPaid (il modulo usato per la gestione di sistemi di e-commerce) per la gestione delle registrazioni al sito della Plone Conference 2010.

L'altro intervento di Matt è stato dedicato alla conferenza organizzata dallo stesso Matt e da Netsight a Bristol (UK).
Matt ha sottolineato che, a parte il fatto che probabilmente non ci sarà lo stesso cibo "faboulus" dell'Hotel Mediterraneo, l'attenzione dell'organizzazione sarà concentrata su molti aspetti, dalla rete affidabile e veloce, agli alloggi per i partecipanti. Inoltre il terzo giorno della conferenza sarà impostato in modalità barcamp come già fatto per Budapest.

Rok Garbas ha presentato 2 argomenti interessanti.

Durante l'intervento dedicato a Transmogrifier ho potuto trovare conferma dei grandi passi in avanti fatti da questo sistema nell'ultimo anno.

L'idea di base è semplice ma molto efficace e realizzata con un codice veramente ben fatto: l'idea è di avere un meccanismo per importare contenuti in Plone. Si tratta di configurare le varie fasi (pipeline) dove, in ognuna, viene fatta una operazione sui dati. Esistono varie moduli che sono già stati realizzati e pacchettizzati per poter gestire alcuni casi tipici (dalla gestione dei CSV, al crawler dei siti da cui è possibile parsare l'html).

Nell'altro intervento Rok ha presentato Deliverance. In questo intervento introduttivo si è potuto toccare con mano l'idea che sta alla base del sistema: fare in modo che i designer Web, che hanno esperienza con l'uso di HTML e CSS, possano fare temi per Plone senza dover per forza imparare tutti i segreti del theming di Plone; argomento che sulle prime prime può mettere un po' in crisi gli aspiranti designer Plone. Rok ha anche passato in rassegna le differenze tra la sintassi di Deliverance e XDV. L'idea di Rok, e portata avanti anche durante lo Sprint dei giorni successivi è quella di trovare una sintassi comune per le funzioni più usate dai 2 sistemi.

...e ancora..

Interessanti anche gli altri interventi dedicati ai casi di studio:

  • Simone Deponti ha presentato il caso di studio per la gestione di un importante sistema di E-Commerce
  • Roel Bruggink & Rob Gietema hanno presentato il caso di studio Humanitas.

Entrambi hanno dimostrato quanto si possa fare con Plone.

Un'ultima considerazione finale.

Ormai seguo gli eventi Plone "ufficiali" da 5 anni (il primo "vero" evento Plone a cui ho partecipato è stata la Plone conference di Vienna del 2005) e durante questo Simposio ho trovato conferma di quanto ho osservato già a Budapest l'anno scorso: l'intera comunità si è evoluta ed è maturata nel corso di questi anni. Questo si può "dedurre" da vari segnali: dal piano a lungo termine di Plone, dallo spessore dei vari talk, ai casi di successo sempre più importanti e significativi, alla intergrazione con altri framework Python based (e non solo) e, perchè no, anche alla crescita professionale della comunità italiana.

Arrivederci a Bristol!

Jun 01, 2010

Sorrento Amberjack Sprint: can you please make my Javascript simpler?!

The Javascript source of collective.amberjack need some love. Not a simple task, but something has been done (and something more will be in future).

First of all: the inherited problems

Version 1.0 of collective.amberjack.core is a simple Plone 4 compatibility version of the old 0.9 released.

When we released this we already know that the Javascript code inside was a mess, but before beginning some kind of refactoring procedure we need to know how the project will be changed in future.

The product has a core got from the Amberjack library, in last years many different programmers take part to the develop, meanwhile the product itself (and also Plone) was changing.

Amberjack original library is framework independent while Plone (that is a smart guy) rely on jQuery. Also we must not forget that Amberjack has not exactly the same target of collective.amberjack...

Wow... how many problems!

Not all those problems will be fixed in the 1.1 version, but I managed to simplify a little the code of two of the main method of amberjackPlone.js source.

How the old amberjackPlone.js was done

Saying "the code is ugly but works" is not a valid excuse... amberjackPlone.js contains two important methods:

  • highlightStep is the method that highlight all the clickable/usable elements in the page for all steps.
  • doStep is the method called to reproduce the user action on the page

What a user can do in a Plone site is a long list of different actions... list that become something like this for highlightStep:

...
if(type_obj=="checkbox" || type_obj=="radio"){
	obj.parent().addClass(theAJClass);
	obj.addClass(theAJClassBehaviour);
}
else if (type_obj=="select"){
	var highlightThis = jq(obj + " option[value="+ AjSteps[num].getValue() +"]");
	highlightThis.addClass(theAJClass);
	obj.addClass(theAJClassBehaviour);
}
else if (type_obj=="multiple_select") {
...
...going on and on...
...
else{
	obj.addClass(theAJClass);
	obj.addClass(theAJClassBehaviour);
}
...

...and like this for doStep:

...
if (type_obj == 'link') {
	AmberjackPlone.setAmberjackCookies();
	location.href = obj.attr('href');
}
else if (type_obj == 'button')
	obj.click();
else if (type_obj == 'collapsible') {
...
...going on and on and on and on...
...

Ugly enough? Do you think that the AntiIfCampaign hate us? Yes... probably...

So the first step is to remove this mess and try to port in Javascript the concept of adapter (unluckily not so flexible as Zope ones).

Even worst: many of the if statement in both doStep and highlightStep was testing the same expressions (like the "select")!

All this code has been removed.

Now both doStep and highlightStep are simply calling a sort of adapter built in the stepAdapters.js file:

AmberjackPlone.stepAdapters = {
	
	link: {
		highlight: null,
		checkStep: null,
		step: function(obj, type_obj, jq_obj, value) {
			AmberjackPlone.setAmberjackCookies();
			location.href = obj.attr('href');
		}
	},
	button: {
		highlight: null,
		checkStep: null,
		step: function(obj, type_obj, jq_obj, value) {
			obj.click();
		}
	},
	collapsible: {
...
... going on and on, but more readable!
...

For every possible action know, highlightStep and doStep will check if an handler is present in this structure (in this example the code is from the doStep):

if (AmberjackPlone.stepAdapters[type_obj] && AmberjackPlone.stepAdapters[type_obj].step)
	AmberjackPlone.stepAdapters[type_obj].step(obj, type_obj, jq_obj, value);

The highlightStep will check for highlight function.

If not if found, perform the old final else statement.

What is the checkStep section? In this sprint another group (Mirco and Simone Orsi) take a look to the feature that test if a user has completed all the steps before can go to the next page. Again, for some possible action the tour can try to test if you have finished your work.

In the old approach this will lead us to a new big and monolithic function. Now is only a new tiny method that call an handler.

What's next?

Adding some documentation, for sure...

Also other part of the code can be changed to become more clear...

...to be continued!

Sorrento Sprint Summary - collective.amberjack progress report

RedTurtle is participating each year in Sorrento's Plone sprints. We were there also last week. It was an amazing time of brainstorming and coding. I will try to make a summary of what we have archived.

Symposium

We have started collective.amberjack presence in Sorrento with Massimo's presentation at the European Plone Symposium

 


Sprint

Then we had two sprinting days. We have started day one with brainstorming. We had three objectives/questions:

  • collective.amberjack sandbox
  • refactoring the code - how to simplify collective.amberjack tour definition and registration
  • translations - how to manage tour/steps translations

thanks to a fruitful discussion (garbas, dukebody, gborelli, miziodel, shywolf9982, sorry if I forgot your name ;-) we have right now answers to all of our dilemmas.


SanDbox

First idea of having a sandbox for collective.amberjack came up at last Plone Conference in Budapest. We have collected a lot of ideas for different use cases. We have had also some internal brainstorms in RedTurtle about it. Finally after confronting all the concepts - during Sorrento brainstorming - we will have a simple solution which should satisfy most of the users:

  • simple Plone site deployment (like demo.plone.org)
  • open registration for all users
  • collective.amberjack preinstalled and ready to use
  • user will try-out Plone using amberjack in his member folder
  • nightly restart with fresh Data.fs


Code refactoring

We have started refactoring collective.amberjack. There are 3 areas of interests: javascript, tour definition and tour registration. Luca was doing a great job trying to simplify javascript part. He also prepare a good startup for future enhancements. I was refactoring tour part. We have decided to use a 

configuration baseD tour definition,

which looks like that:

[amberjack]
steps = 
        0_create-a-new-folder
        1_fill-out-the-fields
        2_publish-the-folder
        3_all-done
title = Add and publish a Folder

[0_create-a-new-folder]
blueprint = collective.amberjack.blueprints.step
title = Create a new folder
url = /
text = Folders are one of ....
validators = 
        python: isManager
        python: isNotFolderCreated
microsteps = 
        0_0_microstep
        0_1_microstep
        0_2_microstep

[0_0_microstep]
blueprint = collective.amberjack.blueprints.microstep
description = If you don't want to perform the ...
automatically done by your browser.

[0_1_microstep]
blueprint = collective.amberjack.blueprints.microstep
idstep = menu_add-new
description = Click the [Add new...] drop-down menu.

[0_2_microstep]
blueprint = collective.amberjack.blueprints.microstep
idstep = new_folder
description = Select [Folder] from the menu.

This concept is well known across the community. I hope it will be also more human readable comparing to python dictionary ;-). We have a working version in the trunk. For new tours we have also 

new tour registration 

- comparing to old approach (registration only using ZCML) you can now use also TTW registration. Other important change is that tour doesn't need to be a python package any more. Because it's a simple .cfg file right now you can simply zip it into an archive (zip, tar) and register it. We have a working implementation for web source and local file system registration (which you can find in the trunk). Archive file can be shipped with multiple tours and with


translationS

which right now are still just a concept that need to be implemented. We would like to make a use of i18ndude tool but because it was designed for ZPT this could be a wrong approach. Overall idea is to keep all the files (tour and the translations) together, something like:

- mytours.zip
  |- tour1.cfg
  |- tour1_en.po
  |- tour1_it.po
  |- tour1.pot
  |- tour2.cfg
  |- tour2_en.po
  ...

 

Fixing bugs

Mirco and Federica were working together and did an enormous job fixing most of the 1.1a release bugs. Thanks to Rob we have solved also some TinyMCE problems that we have had. We have still some open issues, like 'new portlet creation' tour that need some attention so we still need your help!


What's next?

The current development focus is on 1.1 release, which includes:

  • new tour definition (python dictionary based tour will still work until 1.2)
  • new tour registration (old registration will still work until 1.2)
  • finish translation implementation
  • fix last bugs
  • deploy sandbox probably on demo.plone.org
  • collective.amberjack.windmill - which should become default interface for creating and editing tours; we have right now something more then just proof of concept:

May 31, 2010

Sorrento Sprint: collective.amberjack

Come ogni anno da 4 anni abbiamo partecipato al Sorrento Sprint. Quest'anno abbiamo deciso di andare in forze (8 persone) allo scopo di portare avanti lo sviluppo di amberjack di cui ci siamo presi carico nei confronti della comunità.

Gli obiettivi

Abbiamo una milestone da raggiungere: quella del rilascio della versione 1.1a. Questa comprendeva:

  • la risoluzione di alcuni bug o problemi di interfaccia
  • il refactoring del codice javascript
  • il brainstorming su come evolvere il sistema

Abbiamo risolto i bug, introdotti ulteriori miglioramenti all'interfaccia e rifattorizzata buona parte del codice javacript. Rimane qualcosa da finire, nel complesso è stato un successo. 

Inoltre, sono stati introdotti cambiamenti strutturali alla definizione del tour.

Luca, Federica, Mirco ed Andrew hanno fatto un gran lavoro.

Il punto focale però è stato il confronto con la comunità. Avevamo preso alcune decisioni che ci è sembrato opportuno sottoporre al vaglio dei presenti e abbiamo ottenuto ottimi suggerimenti e conferme sulla strada intrapresa.

Windmill

Windmill diventerà l'interfaccia principale di creazione di un tour. E' il modo più semplice per crearlo, aggiornarlo, tradurlo. E' di enorme efficacia sia per un end-user in quanto servirà poco addestramento che per uno sviluppatore che potrà creare al tempo stesso un tutorial per i suoi add-on e un test funzionale che verifichi che l'introduzione di modifiche non inficino il comportamento generale del sistema.

Questa conferma ha portato ad alcune riflessioni e variazioni di indirizzo.

formato dei tour

Il formato cambia. Non più complessi dizionari scritti in python, ma file di configurazione altamente leggibili. qualcosa del tipo:

[amberjack]
steps = 
        0_create-a-new-folder
        1_fill-out-the-fields
        2_publish-the-folder
        3_all-done
title = Add and publish a Folder


[0_create-a-new-folder]
blueprint = collective.amberjack.blueprints.step
title = Create a new folder
url = /
text = Folders are one of ....
validators = 
        python: isManager
        python: isNotFolderCreated
microsteps = 
        0_0_microstep
        0_1_microstep
        0_2_microstep


[0_0_microstep]
blueprint = collective.amberjack.blueprints.microstep
description = If you don't want to perform the ...
automatically done by your browser.


[0_1_microstep]
blueprint = collective.amberjack.blueprints.microstep
idstep = menu_add-new
description = Click the [Add new...] drop-down menu.


[0_2_microstep]
blueprint = collective.amberjack.blueprints.microstep
idstep = new_folder
description = Select [Folder] from the menu.

Sarà ovviamente possibile salvare i tour, in questo nuovo formato, direttamente dall'interfaccia di Windmill.

Ovviamente è necessario avere un sistema di conversione dei vecchi tour: è stata creata l'utility "tour_converter" (in collective.amberjack.core) che migra vecchi dict-based tour in nuovi cfg-based tour.

I tour saranno quindi semplici file. Questo significa che la sorgente da cui verranno "pescati" non sarà più un package scaricabile da pypi, ma potrà essere salvato in locale, messo su un server condiviso, scaricato da sorgenti eterogenee (svn, http server, ftp, ecc.). Ovviamente abbiamo una registrazione "classica" via zcml oppure una più "cool" via pannello di controllo di plone.

E' già pronta e funzionante una versione experimental che funziona con questo nuovo approccio e i 12 plonetour sono stati già convertiti e pronti per l'uso.

Un discorso a parte per le traduzioni: dobbiamo reimplementare il meccanismo in quanto ora non abbiamo più file .py. Contiamo di definire una modalità di traduzione simile alla precedente, ma in qualche modo occorrerà effettuare qualche variazione al sistema di generazione dei file .po.

sandbox

Il brainstorming pre-serale in giardino è stato molto utile anche in questo caso. 

L'idea che ne è scaturita è quella di fornire un folder personale dedicato ai tour all'interno del quale l'utente abbia tutti i diritti necessari per poterli eseguire completamente. Questo copre il 90% delle situazione secondo le previsioni della maggior parte dei presenti.

Con questa sandbox 1.0 si potrà già creare un "demo.plone.org": chiunque potrà provare Plone senza doverlo scaricare.

Inoltre è semplice per ogni sviluppatore di add-on montare un'istanza in cui includere il proprio tour ed eventualmente richiedere alla foundation il dominio: "demo.myaddon.plone.org"

Assolutamente semplice sarà fornire un sistema che ogni notte ripristini il portale ad una situazione "pulita".

Non sembra interessare, almeno in questa fase, un sistema che automaticamente crei un'istanza on-the-fly che permetta all'utente di provare plone in completa autonomia. quel 10% di target-user possono tranquillamente utilizzare un comodo UnifiedInstaller