vienna.info: realising the official viennese tourism website with plone

www.vienna.info

realising the officialViennese tourism website

with Plone

overview

+ facts & figures (about vienna.info)

+ using Plone as back-end and usability

+ separated front-end using skinny

+ partial caching with Varnish and ESI

+ Wienlets (a Portlets alternative)

facts & figures » history

+ before: proprietary, custom build CMS

+ 10+ editors working full-time

+ heavy customizations necessary to meet the demands of content and editors

facts & figures » economical

+ Vienna is among the top-10 destinations in Europe

+ Overnight stays

+ 2008: 10.2 million

+ 01-08 2009: 6.3 million

+ Touristic value added: ~ 4 billion Euro / year

facts & figures » stats

+ 13 languages(12 in Plone, Chinese in China)

+ 5,500 articles

+ 3,500 images

+ 320,000 visits/month

+ 1.7 million pageviews/month+ 2,000 events, 390 hotels (external)

using Plone as editorial back-end

+ securely seperated back-end

+ good language management

+ quick navigation and link-management

+ efficient media management

link-management » problem

+ default link-popup is not suitable for multiple languages(editors don't speak Arabic or Japanese)

+ Too slow and inefficient(lots of clicks)

+ No indication of language and workflow-state

using Plone as editorial back-end

link-management » approach

+ jQuery dialogtabbed interface

+ search with autocomplete(title or path)

+ display workflow-state icons

+ usable everywhere(TinyMCE, Category-Layout, …)

using Plone as editorial back-end

demo: Link-Dialogusing Plone as editorial back-end

media-management » problem

+ need alternative text in 12 languagesLinguaPlone doesn't provide „multilingual“ objectsauto-translating images on creation

+ use correct language automatically(in RichText, galleries, etc.)

+ unified dialog for searching images everywhere

using Plone as editorial back-end

media-management » approach

+ jQuery dialog

+ search based lookup by titletitle = keywords (autocomplete id)

+ display title and keywords as context info

+ filter images by aspect-ratio tagsautomatically assigned on upload

using Plone as editorial back-end

using collective.searchtool, archetypes.searchwidget

demo: Media-Browserusing Plone as editorial back-end

category-layout » requirements

+ index page for folders

+ teasers of contained articles

+ easy handling is vital

+ different layout options

+ two, two-by-two or three columns

+ columns contain teasers or RichText

using Plone as editorial back-end

category-layout » approachusing Plone as editorial back-end

+ ajax based solutionquick editing

+ use Link-Dialog(select articles)

+ use Media-Browser(select images)

+ drag & drop sorting

+ progressive disclosure(lots of controls)

demo: Category-Layoutusing Plone as editorial back-end

separated front-end using skinny

+ Existing ways of skinning

+ conventional

+ jbot

+ Deliverance

+ Separate application

+ Skinny

+ How Skinny works

ways of skinning » conventional

+ it's complicated(front-end developers have to be hardcore coders)

+ they have to know about portlets, viewlets, ZCML, Python, CMF skins

+ works fine for small changes to Plone skin

+ the bigger the changes the uglier

separate front-end using skinny

ways of skinning » jbot

+ fixes some problems with the convenitional way

+ no more ZCML for overriding templates

+ shares some problems with conventional

+ still modifying an already heavy skin

+ still need to know a lot of technology(register new viewlets etc.)

separate front-end using skinny

ways of skinning » Deliverance

+ proxy between Plone and the browser

+ transforms Plone's HTML (only rearranging it)

+ then putting CSS on top of it

+ no separation between edit and public interface

+ dynamic content only in the conventional way

+ still renders the full Plone interface: slow

+ more components involved than conventional

separate front-end using skinny

ways of skinning » separate app.

+ full separation between public and editing interface

+ choose out of Django, BFG, bobo, …

+ can't use the same ZODB(without using the same software)

+ a separate databasecomplication: extract all data etc.

separate front-end using skinny

ways of skinning » Skinny

+ full separation of public and editing interface(separate URLs)

+ works within Plone and with ZPT (and views)

+ render your own HTML(for sites with strict requirements)

+ only render what you need: fast public interface

+ don't mess with the editing interface(we want to keep it the way it is!)

+ doesn't work for community websites

separate front-end using skinny

how Skinny works

+ it's a package to include in your buildout(comes with an example skin)

+ only templates and resources for designers

separate front-end using skinny

how Skinny worksseparate front-end using skinny

how Skinny works

+ two rewrite rules per site(one for public, one for edit interface)

+ no new technology or extra configuration

+ you can reuse Plone views, viewlets, portlets

+ but for large sites, you probably want to roll your own everything

separate front-end using skinny

partial caching with Varnish and ESI

how it works

+ caching server

+ retrieve content from Plone and cache it, deliver from cache if applicable

partial caching with Varnish and ESI

how it works

+ application (Plone) sets caching headers(for both Varnish and browser)

+ define additional rules in Varnish's .vcl file like:

+ Turn on ESI(edge side includes)

+ Cache rules for ESI parts(ESI caching headers are ignored)

+ Add login state to the hash

partial caching with Varnish and ESI

how we use itpartial caching with Varnish and ESI

+ we don't use CacheFuwe use plone.postpublicationhook to set headers

+ total control (and better understanding of)over caching headers

+ HTML has 1 hour of TTL in Varnish(no caching in browser)

+ some parts of the site change per user(myVienna, geotargeted)

+ the rest should still be cached by Varnish ESI→

how we use itpartial caching with Varnish and ESI

how we use itpartial caching with Varnish and ESI

Wienlets (a Portlets alternative)

+ normal browser views (not viewlets)

+ retrieve and store information using annotations

+ base classes exist for globally or locally configured wienlets

+ easier to write than Plone 3 portlets

Wienlets (a Portlets alternative)

+ one portlet is actually two views

+ edit view (in Plone)

+ public view (in Skinny)

+ special requirement:block individual wienlets from inheriting

+ three states: inherit, on, or off

questions?

+ Fabian Büchler (WIENFLUSS)buechler@wienfluss.net

+ Daniel Nouridaniel.nouri@gmail.com