2012 ·English ·29 slides ·1652 views

Pragmatic plone projects

This document summarizes a presentation about pragmatic approaches for Plone projects. It discusses customizing Plone and third party packages through various methods like monkey patching, overrides, and extending schemas. It also provides an example of a large company portal project built on Plone 4.2 for Weishaupt, a major heating systems vendor.

Source PDF 4.3 MB Slide text

Slide 1 of 29 — Pragmatic plone projects

1/29 arrow keys or swipe · click image for fullscreen

Details

Uploaded: 10 October 2012
Updated: 7 December 2022
Language: English
Slides: 29
Image size: 2048x1447
Views: 1652
SlideShare ID: 14668107
Uploaded format: PDF
Collected: 2026-09-27

The description above is SlideShare's automatically generated summary, not the author's own text.

Source & completeness

Content: original + reconstructed
Validation: passed
Slide text: available (29 slides)
Original files: yes

original.pdf PDF · 4.3 MB · 29 slides

Checksums (SHA-256)

original.pdf: 62d5fc102b454a2b14f22574efe6c643f6c4a4fb638b3796177178adff2827da

Slide images come from SlideShare's public renderings (2048x1447 px, WebP). Any file marked as reconstructed is assembled from those images and is not the author's original source file.

Full text of every slide

Text extracted by SlideShare from the slide images — may contain OCR errors. 29 of 29 slides have text.

Pragmatic Plone Projects Plone Conference 2012 Arnhem Andreas Jung ZOPYX Ltd. www.zopyx.com, info@zopyx.com

Speaker •  long-‐time Python, Zope, Plone developer and contributor •  Lead developer and principal consultant of ZOPYX Limited –  Zope, Python, Pyramid, Plone projects –  large portals, intranet, internet, extranet –  Electronic Publishing –  complex domain-‐speciﬁc applications

This talk is about •  practical hints surviving your next Plone project •  best practices •  lessons learned from our last larger Plone project •  stuﬀ perhaps covered already by the Plone trainings

Relaunch weishaupt.de •  Weishaupt: –  major vendor of heating systems –  480 M€ revenue •  Large company portal on top of Plone 4.2 •  Phase 1: –  implementation and DE content –  4 months •  Phase 2: –  20 subsidaries –  more than 30 languages

weishaupt.de

Project constraints (1/3) There is no real-‐world project with •  unlimited budget •  unlimited human resources •  unlimited time

Project constraints (2/3) Resources Budget Time

Project constraints (3/3) Conclusions •  usually impossible ﬁnding the „perfect“ solution •  the „perfect“ solution is „mission impossible“

Getting things done •  within a reasonable time-‐frame •  on budget •  with the available human resources

Common customizations •  Bugs in Plone and 3rd-‐party packages are all around you •  Particular behavior of Plone or 3rd-‐party packages is a common project requirement •  What must be usually customized: –  Python code (browser views, skin scripts) –  Resources (browser view templates, JS, CSS)

Where to ﬁx things? •  Package maintainer (Plone and 3rd-‐party) love –  bug reports –  bug ﬁxes –  contributions •  Stuﬀ on Github: Fork & Pull request •  SVN repositories: svn branch & svn merge –  check if the package is maintained –  ask the maintainer for merging your changes or merge yourself –  move packages to Github if appropriate

Where and how to customize things? •  Is your required change of interest for the public? –  fork on Github –  branch in SVN –  speak with the package maintainers •  Your change satisﬁes an absurd customer request? –  keep it for yourself.

(Monkey) Patching Python code •  Monkey patching: „dynamic modiﬁcations of a class or module at runtime“ (Source: Wikipedia) •  MP in general should be considered evil and bad-‐style •  MP may have side-‐eﬀects •  Use MP carefully (and only when you know what you are doing)

Monkey patching in Python Original (foo.py) Patched version (my_foo.py) class Foo:! def my_bar(self):! ! return 43! def bar(self):! ! return 42! from foo import Foo! Foo.bar = my_bar! ! # or (needed in some situations)! ! Foo.bar.func_code = my_bar.func_code!

Monkey patching Plone collective.monkeypatcher (patches.zcml) ZCML-‐level conﬁguration of patching <configure...>! <include package="collective.monkeypatcher" />! information: <monkey:patch! •  module-‐level patches description="ISE-42: OFS.Image.tag()"! •  class-‐level patches class="Products.CMFCore.FSImage.FSImage"! original="tag"! replacement=".patches.tag"! />! </configure>! collective.monkeypatcherpanel (patches.zcml)

Patching resources (1/2) – overrides.zcml •  Standard mechanism for overriding conﬁguration settings introduced through a diﬀerent package •  overrides.zcml is an optional ZCML conﬁguration ﬁle Products.PloneGlossary (conﬁgure.zcml) my.package (overrides.zcml) <configure..> ! <configure..> ! <browser:page! <browser:page! name="glossary_main_page“ ! name="glossary_main_page"! for="Products.PloneGlossary.IPloneGlossary"! for="Products.PloneGlossary.IPloneGlossary"! class=".pages.GlossaryMainPage"! class=".glossary.GlossaryView“! permission="zope2.View“ />! permission="zope2.View“ />! </configure>! </configure>! !

Patching resources (2/2) – z3c.jbot •  z3c.jbot allows you to override resources of other packages inside your own policy package •  Limited to .pt, .cpt, .js?! Conﬁguration: <browser:jbot directory=“overrides“ /> Existing template: plone.app.search/plone/app/search/search.pt Customization: your.package/your/package/overrides/plone.app.search.search.pt Links •  http://blog.keul.it/2011/06/z3cjbot-‐magical-‐with-‐your-‐skins.html •  http://pypi.python.org/pypi/z3c.jbot

Unconﬁgure resource conﬁgurations •  Sometimes you just don‘t want or need ZCML conﬁgurations introduced by other packages •  z3c.unconﬁgure is your friend some.package(conﬁgure.zcml) my.package (conﬁgure.zcml) <configure..> ! <configure..> ! <browser:page! <include package="z3c.unconfigure" ! name="glossary_main_page“ ! file="meta.zcml" />! for="Products.PloneGlossary.IPloneGlossary"! <unconfigure>! class=".pages.GlossaryMainPage"! <browser:page! permission="zope2.View“ />! name="glossary_main_page“ ! </configure>! for="Products.PloneGlossary.IPloneGlossary"! class=".glossary.GlossaryView“! permission="zope2.View“ />! </unconfigure>! </configure>!

Extending schemas Plone comes with two content-‐type systems •  Archetypes (old-‐style) –  use archetypes.schemaextender –  modify any AT-‐based content-‐type (modifying ﬁelds, adding ﬁelds) –  SchemaExtender, SchemaModiﬁer •  Dexterity (new-‐style) –  Dexterity introduces „behaviors“ –  „A behavior is a re-‐usable aspect of an object that can be enabled or disabled without changing the component registry“ (Source: Dexterity developer manual)

Keep your designer happy Implementing CSS styles requires representative content http://localhost:8080/@@new-site?content=1!

Auto-‐generated content

Predeﬁned sample content •  Write a browser view –  creating a Plone site with policy package + add-‐ons –  installing the basic site-‐structure –  creating example content for each content-‐type, content-‐ listing etc •  use http://lorempixel.com/600/400 ... •  look at loremipsum, collective.loremipsum or zopyx.ipsumplone

Predeﬁned sample content •  Throw your sandbox/Plone working site away as often as possible •  sometimes I created 30-‐40 new Plone sites per day •  Pragmatic side-‐eﬀect –  the content ﬁxture code can be used as unit test where all your content-‐types and site-‐infrastructure is created and tested in one run –  not the best solution but it works reasonably well

Some good hints •  Never ever perform customizations in-‐place in existing 3rd-‐party packages. NEVER!!! •  Customizations always belong into your own policy package. •  Local customizations of 3rd-‐party package will be lost with the next version of customized package.

Questions?