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
