+ 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) Video: http://blip.tv/plone-videos/daniel-nouri-and-fabian-b-chler-www-vienna-info-realising-the-official-viennese-tourism-website-with-plone-3207159

1. www.vienna.info
realising the official
Viennese tourism website
with Plone

2. 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)

3. facts & figures » history
+ before: proprietary, custom build CMS
+ 10+ editors working full-time
+ heavy customizations necessary to meet the
demands of content and editors

4. 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

5. 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)

6. using Plone as editorial back-end
+ securely seperated back-end
+ good language management
+ quick navigation and link-management
+ efficient media management

7. using Plone as editorial back-end
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

8. using Plone as editorial back-end
link-management » approach
+ jQuery dialog
tabbed interface
+ search with
autocomplete
(title or path)
+ display workflow-state
icons
+ usable everywhere
(TinyMCE, Category-Layout, …)

9. using Plone as editorial back-end
demo: Link-Dialog

10. using Plone as editorial back-end
media-management » problem
+ need alternative text in 12 languages
LinguaPlone doesn't provide „multilingual“ objects
auto-translating images on creation
+ use correct language automatically
(in RichText, galleries, etc.)
+ unified dialog for searching images everywhere

11. using Plone as editorial back-end
media-management » approach
+ jQuery dialog
+ search based lookup by title
title = keywords (autocomplete id)
+ display title and keywords as
context info
+ filter images by aspect-ratio
tags
automatically assigned on upload
using collective.searchtool, archetypes.searchwidget

12. using Plone as editorial back-end
demo: Media-Browser

13. using 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

14. using Plone as editorial back-end
category-layout » approach
+ ajax based solution
quick editing
+ use Link-Dialog
(select articles)
+ use Media-Browser
(select images)
+ drag & drop sorting
+ progressive disclosure
(lots of controls)

15. using Plone as editorial back-end
demo: Category-Layout

16. separated front-end using skinny
+ Existing ways of skinning
+ conventional
+ jbot
+ Deliverance
+ Separate application
+ Skinny
+ How Skinny works

17. separate front-end using skinny
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

18. 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.)

19. 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

20. 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 database
complication: extract all data etc.

21. 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

22. 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

23. separate front-end using skinny
how Skinny works

24. separate 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

25. partial caching with Varnish and ESI

26. partial caching with Varnish and ESI
how it works
+ caching server
+ retrieve content from Plone and cache it,
deliver from cache if applicable

27. 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

28. partial caching with Varnish and ESI
how we use it
+ we don't use CacheFu
we 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

29. partial caching with Varnish and ESI
how we use it

30. partial caching with Varnish and ESI
how we use it

31. 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

32. 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

33. questions?
+ Fabian Büchler (WIENFLUSS)
buechler@wienfluss.net
+ Daniel Nouri
daniel.nouri@gmail.com