Some months ago I posted (Italian only) about Check_mk as a monitoring tool which can be used also to taking care of Plone instances. This time I will post a small custom plugin I wrote for Nagios.

Check_mk scan_port plugin

Il tab "contenuti" di Plone, è una comoda vista delle cartelle (o contenuti "cartellosi") che permette di avere una visione generale degli elementi contenuti al suo interno.

Con questa vista si possono anche fare alcune operazioni come il copia/incolla di contenuti, il riordino di elementi trascinandoli e cambiare il criterio di ordinamento dei contenuti visualizzati a seconda di alcuni indici come il titolo o la data di modifica.

E se noi volessimo uno strumento più completo, e fare operazioni più complesse?

Did you ever wanted...

... to just include the main content from a Plone page in an iframe and for this reason struggled with customized views and CSS rules to remove unwanted page elements like portlets, viewlets, footer and so on?

Did you know...

... that there is a simple and easy way to request Plone to serve a page with only the main content, skipping all the surrounding elements for navigation?

For the impatients

To embed a page inside an iframe, since Plone 4.0.3,  you have the option to include just the main content by appending the query string: ?ajax_load=1&ajax_include_head=1, to the URL inside the src attribute.

La priorità: capire cosa è un sottosito

Prima di addentrarsi nella scelta di una delle soluzioni Plone per gestire sottositi, è bene iniziare il tutto con un'esame della propria organizzazione (o di quella del Cliente che vi ha richiesto "Plone e sottositi") per capire che cosa è un sottosito agli occhi dell'utilizzatore finale.

Può sembrare un passo inutile e dal risultato ovvio in quanto ogniuno di voi avrà in questo momento un'idea ben precisa ma posso assicurarvi che in questi anni abbiamo potuto vedere come questo concetto possa essere percepito in modo molto diverso.

Diamo innanzi tutto una definizione abbastanza generica da poter essere corretta in ogni caso (che dite, la scrivo anche su Wikipedia?).

Un sottosito è una porzione di un sito più grande ma che risente di un certo grado di indipendenza, pur mantenendo un legame col sito principale o con eventuali sottositi fratelli.

Fin qui tutto ok ma in seguito inizieranno ad emergere dettagli e molto spesso le similitudini tra le differenti richieste finiranno qui.

Le variabili in gioco sono le seguenti: indipendenza e legame col sito principale. Tutti vedono queste due caratteristiche in modo molto diverso.

Il nostro lavoro in questi casi è sempre stato analizzare innanzi tutto che cosa l'utente vuole ottenere.

Non ci siamo sorpresi quando alle volte il concetto di sottosito si è fermato alla richiesta di avere un dominio diverso col quale poter navigare una parte del il sito principale (e.g: sottosito.ente.it) oppure alla semplice applicazione di un tema differente. Non c'è nulla di male: un logo differente, o poco più, alle volte è tutto quello che i vostri utenti si aspettano e basta ai visitatori del sito per dare il giusto messaggio.

Gradi di indipendenza dal sito madre

Vediamo i vari scenari che si possono presentare.

Indipendenza 0%, legame col principale 100%

E' l'esempio fatto poco fa. Stiamo quindi parlando di siti dove l'indipendenza è nulla mentre il legale col sito principale è completo. L'utente ha solo bisogno di un richiamo visuale che identifichi l'entrata in un dipartimento diverso, una sottosezione dell'ente o della compagnia, etc.

Indipendenza 100%, legame col sito principale 0%

Altro non infrequente esempio è lo sviluppo di tanti piccoli sottositi, potenzialmente diversi tra loro in tutto.

Al termine dell'analisi di queste situazioni ci vede essere da parte vostra la lecita domanda "Ma perché dite che vi serve un sottosito? Quale è il legame col sito principale?".
Anche in questo caso non stupitevi se la risposta a volte è "Nessun legame!".

Molto spesso l'utente ha davvero bisogno di siti Plone completamente separati che condividono semplicemente:

• i prodotti installati
• una base dati utente comune (ma non è detto)
• l'uso di un dominio principale condiviso (ente.it/sottosito oppure sottosito.ente.it)

In questi casi Plone risolve da solo brillantemente la necessità, permettendovi di creare siti Plone separati nella stessa istanza Zope. Non vi serve altro!

La verità sta nel mezzo

Ovviamente nella maggior parte dei casi si ha "la sana via di mezzo".

In questa zona grigia molto spesso non vi serve chissà quale prodotto installato, ma qualche piccolo accorgimento.

Un esempio reale:

"i sottositi dovranno essere completamente indipendenti ma il link "Home" delle briciole di pane deve puntare al sito principale".

Quindi la Home del sottosito parte in realtà dalla seconda voce. Come otteniamo una cosa simile? Una semplice modifica che personalizzi la viewlet che genera questo elemento, per inserire un link assoluto al sito base. Per il resto: siamo ancora in presenza di un ambiente altamente indipendente. Il vostro "Plonista di fiducia" può farvi ottenere questo comportamento con poche ore di lavoro!

Da qui possiamo incontrare casi dove l'indipendenza cala piano piano e i prodotti da personalizzare ed installare crescono e si complicano...

Quando arrivate a questo, vale la pensa guardarvi attorno a capire che cosa vi serve davvero, e verificare che cosa Plone vi offre.

Altri prodotti che SI OCCUPANO DI sottositi

La necessità di ottenere sottositi è largamente sentita in Italia (forse anche legata alle recenti norme di razionalizzazione dei siti esistenti per gli Enti Pubblici) ma assai meno all'estero.

Al termine della Plone Conference di Budapest ho partecipato ad un Open Space dove si è parlato di sottositi, ma per il resto abbiamo dovuto faticare, inviare segnalazioni, discutere ed aspettare perché Plone ci facilitasse questo comportamento. Anche le discussioni a riguardo non sono poi tante (vale la pena leggere "Subsites in Plone: Review of info and call for sharing products, experiences, and best practices").
Ad oggi l'unico prodotto che sembra abbastanza mantenuto e aggiornato che si occupa di questa necessità è Lineage.

... almeno fino al rilascio del nostro prodotto!

Ad ogni modo con la release 4 il nostro CMS preferito è diventato un ottimo ambiente per avere sottositi.

Fare sottositi in Plone senza usare Plone: redturtle.subsite

La natura di redturtle.subsites si riassume in questo. Spostare al di fuori di Plone (Apache) tutta una serie di problematiche che, grazie a funzionalità native di Plone (anche se poco conosciute) è possibile gestire senza codice aggiuntivo.

Il prodotto nasce da alcuni esperimenti di RedTurtle ma viene portato poi avanti grazie alle esplicite richieste del Comune di Modena, che ha sentito da molti anni questa necessità in alcune installazioni ed è quindi un precursore dell'esplorazione dei sottositi in Plone.

Siamo in presenza di sottositi dove il rapporto "indipendenza/legame col principale" è variabile, ma comunque molto spostata verso un livello di bassa indipendenza ed altra integrazione: i sottositi fanno tutti parte della Rete Civica e questo non viene mai completamente nascosto.

Descriviamo nel dettaglio le richieste originali.

Back-end

I redattori dei sottositi devono poter accedere ad un indirizzo di back-end (anche detto "back-office") riservato, e si autenticano da quell'indirizzo (qualcosa come redazione.ente.it).

La caratteristica del back-end è quella di nascondere completamente tutto ciò che identifica i sottositi e mostrare il sito Plone principale. I sottositi risultano quindi semplici cartelle all'interno del portale visitato.

Anche il tema grafico può essere personalizzato fino ai limiti dello spartano, eliminando tutto quello che occupa spazio visivo nello schermo del redattore (o perché no, aggiungendovi elementi che abbiano il solo scopo di facilitare la redazione).
Il tema diventa quindi un vero e proprio tema riservato al back-end (ma non è obbligatorio).

Il redattore può quindi facilmente eseguire link interni (usando l'editor di Plone) tra documenti di sottositi diversi, creare collezioni che catturino informazioni da più sottositi, ...

Front-end

Questo comportamento deve cambiare nel front-end. Quando il visitatore accedere ad un sottosito deve ovviamente vedere il tema applicato a questo, ma deve avere un livello di integrazione col sito principale molto più basso.

I link alla home del sito, dal logo e dalle briciole di pane, devono riferirsi al sottosito corrente, non a quello principale.

Se non fosse per le ricerche effettuate nel sito o per la presenza di collezioni che qua e là possono mostrare contenuti proveniente dagli altri sottositi fratelli, potrebbe quasi sembrare di trovarsi all'interno si un sito Plone separato.

Con Plone è estremamente semplice (leggasi "senza installare nulla") isolare una cartella perché questa funzioni come un sito indipendente, ma questo influenzerebbe sia il back-end che il front-end (livello di indipendenza troppo elevato).

La nostra soluzione

Il nostro prodotto offre un modo estremamente semplice e poco invasivo di avere:

• un back-end che nasconda completamente i sottositi
• un front-end che mostri alcune cartelle come sottositi
• una metodologia semplice per creare temi aggiuntivi per questi sottositi

Creare uno di questi temi per i sottositi, o personalizzare un tema esistente, è estremamente semplice.

Il prodotto offre già alcune piccole personalizzazioni di Plone (modificandolo il meno possibile) per non dover sviluppare nessun codice aggiuntivo. Abbiamo anche fornito un tema di esempio per un sottosito Plone.

Le altre caratteristiche fornite sono:

• la navigazione di front-end interna al sottosito è altamente limitata al sottosito stesso (briciole di pane, link alla radice, ...)
• le ricerche sono eseguite a livello globale
• le collezioni comprendono tutto il sito (viene lasciato quindi al redattore il compito di limitarle, se lo desidera)
• ipotetici redattori di front-end (utenti esterni alla redazione) sono fortemente limitati, come se stessero lavorando in un sito Plone indipendente

Conclusioni

Il prodotto redturtle.subsite è semplicemente un aggregatore di tutta la splendida tecnologia sottostante e la pagina ufficiale del prodotto può essere vista come un manuale dei sottositi in Plone, per chiunque volesse intraprendere la strada (anche senza voler per forza usare redturtle.subsite potreste trovare informazioni interessanti).

La sua limitata dimensione dimostra come Plone sia di per se uno strumento estremamente maturo e, lasciatemelo dire, ancora una volta pieno di belle sorprese!

It has been a tiring but exciting week in Florence.

After four years of national PyCon Italy, the team has been excellent and set up an event that clearly shows the level of maturity of the community.

Over the years since the first EuroPython conference, the big change is that we don't have to justify our language choice anymore.

Actually, I would not even be a programmer it where was no Python. I was a system administrator, more like a plumber than an internal decorator.
Python has taken me by hand, teaching and letting me write things I would not have attempted in other languages available at the time.

As programmers, we make trade-offs and take compromises several times per day, while we design and write applications.
Very often we take a different road than we did the day before, because we've seen what lays ahead and want to avoid it, or the customer has changed his mind, or we have a better understanding of the whole.

As a matter of fact the right answer to a programming question is often "it depends", because the architectures, markets and business models are getting more and more complex, and we as software craftsmen have none of the certainties than mathematicians or computer science people take for granted.

Fortunately for us and our customers, software can be easily changed, and nothing prevents experimenting with different approaches if time allows.
But once in a while - typically at the start of a development cycle - we have bigger choices, the decisions that make room for the following ones: the basic architecture.

• What language(s) are we going to use? (that's easy, Python. but it depends)
• Light framework or a heavy, full featured one?

• Relational or non-relational database? And if non-relational, which of the many?
• Is our application process or data driven, or both? (this is vague. it's usually both)
• Browser or server side processing?
• How will it scale to many concurrent users?

and so on, and on.

At this point, if we pick the wrong road, the application could still be delivered, hopefully in time and the customer will be happy (at first), but the program itself might be a lot more complicated than it needs to be, and hard to change. The price will be paid over time, as new needs come and maintenance is required.

Unfortunately for us, some of these are hard questions, also subject of fashions and marker pressure, and it is very hard to have a comprehensive picture just by following technical blogs.

That's why I long for conferences like EuroPython, where the scope of the talks is as wide as can be, while still remaining highly technical.
Where the authors are ready to discuss about it over the lunch, and everybody is smart for having chosen Python :-)

Best talks.. ever :-)

A few of the talks tackling old problems in light of new tools and experiences:

Relate or !Relate (Mark Ramm-Christensen)

Mark explains the difference between the forest of NoSQL databases, and shows that a good SQL DBMS can scale surprisingly well.
This is a dear topic to me, because direct approaches in one side require complex contraptions on the other one, and vice-versa.
As a side note, lately the MySQL - Postgres debate seems to be over. The latter one has sharply won, if not the market, the minds of the programmers.

How to build complex web applications having fun? (Andrew Mleczko)

If the user wants both, give them both. Instead of fitting every requirement in a single architecture, try deploying a full-featured
CMS along with a light, flexible framework and divide the tasks -- a little like loading a bike on your camper.
You can go anywhere and they integrate well.
This is easier today (in the post-WSGI world) thanks to Pyramid, a highly refined foundation for web applications that lets a lot
of freedom: should the architecture be modeled after Zope, Plone, Pylons, Turbogears, Rails or Django? With Pyramid, "it depends" is the main concept :)

Other worth mentioning

• Challenges in developing a large Django site (Simon Willison)
• An iPhone-Python love affair: Building APIs for mobile (Anna Callahan - Nate Aune)

I also had fun with Raymond Hettinger, the only developer I've known that adds a +1 charisma bonus within a 10mt radius.

In his training track, he tore apart core concepts of Python (classes, decorators, properties, descriptors, dictionaries) and as he spoke rebuilt them using lists only. MacGyver couldn't do better!

But really, I could list half of the talks in the schedule, they are that good, and they kept a good balance of more and less advanced matters.

and the plone-ish stuff?

Sure, I would have liked a few more talks about Zope, Plone, BlueBream or Grok, especially highlighting how they have changed in the latest years, becoming more powerful, easier to extend and deploy, and there should be some effort communicating that to new developers.

They are coming to the conference to look for directions, and might go after some fashionable, but less capable tools.