Content Management Systems

1
Content Management Systems

• CSCI 4300

2
Zope Application Server
3
Zope Application Server explained

• Maintains objects in an object database
• (not Java objects)
• Zserver Built-in Web server
• WebDAV File transfer mechanism
• XML-RPC Remote Procedure call
• Zope product Web app running on Zope

4
A typical Plone site
5
Plone and Zope 3

• Zope 3 is the new, cooler, faster, sexier version
  of Zope. Unfortunately, there is no direct
  migration path from Zope 2 to Zope 3. However, we
  are beginning to use Zope 3 technologies in
  Plone, alongside the Zope 2 core.
• Zope 3 is a fairly different way of programming.
  It is based on the principle of components, that
  expose their functionality through well-defined
  interfaces. Whereas in Zope 2, you would need to
  mix classes into the inheritance hierarchy to
  gain certain functionality, for example by mixing
  in CopySupport to get cut/copy/paste support,
  Zope 3 uses the principle of adapters.
• An adapter is simply a piece of glue code that
  can adapt an object to a given interface, so that
  the original object itself doesn't need to know
  anything about that interface or what it does.
  This makes it easier to re-use other Python
  objects that are not Zope aware, and makes
  components smaller, more precisely defined and
  thus easier to re-use.
• Other types of Zope 3 components include
  utilities - stateless, global objects that can be
  looked up through a generic registry, and views,
  a special type of adapter that is typically used
  to contain the logic of page templates in a way
  that is more performant and easier to test.

6
Plone Bug Fixes Unit Testing

• Every feature, bugfix and other part of Plone
  should be properly unit tested, and all unit
  tests should be run and made to pass before each
  commit. Read on for more.
• Plone is a large and complex system. Were you to
  blindly change some feature, you would probably
  break another one in ways you could never have
  imagined. Therefore, good unit testing is vital
  to the survival of Plone. Every feature needs a
  set of unit tests for base cases and edge cases.
• Don't look at unit testing as some necessary
  evil Unit testing actually makes testing fun!
  Ideally, you should write tests before you
  implement your code or make changes. Your mission
  is then to make the tests pass. This is generally
  much easier and more enjoyable than fiddling with
  things in UI. Unit tests also save you time in
  the long run, because you are less likely to let
  obscure bugs go unnoticed, or break code which
  you thought worked with seemingly "harmless"
  changes.
• Fixing bugs
• When you fix a bug in Plone, you must write at
  least one unit test to prove that it's there!
  That test should fail the first time you run it.
  Then fix the bug and run the test again. This
  time, the test must pass. Be sure to test Plone
  in the browser too, and run all the unit tests
  before commiting your bug fix.

7
Coding for Performance

• If there is one axiomatic law of performance in
  Zope and Plone it is this Do not wake up objects
  unless you need to. "Waking up" objects refers to
  pulling them out of the ZODB - traversing to
  them, loading them into memory. This is an
  expensive operation.
• In general, we prefer to use catalog queries to
  find objects.
• portal_catalog getToolByName(self,
  'portal_catalog')
• results portal_catalog.searchResults(path
  'query'
  '/'.join(self.getPhysicalPath()), 'depth' 1)
• for brain in results ...

8
Avoiding 404s defensive coding

• A 404, or a NotFoundException in Zope, is an
  expensive operation. 404s can occur unnoticed
  when a page template references and image or
  stylesheet that does not exist. Be careful about
  referencing items that may or may not exist. You
  can code defensively by doing something like
• lttalblock condition"existssome-name"gt
• ...
• lt/talblockgt

9
Making pages cacheable

• One of the ways in which real-world installations
  make Plone faster is by using cacheing, for
  example via CacheFu. It is important that we make
  pages and elements of pages as easy to cache as
  possible. Most of the time, this simply boils
  down to avoiding unnecessarily dynamic elements.
• Take the sitemap, for example. Constructing this
  is an expensive operation, since the sitemap view
  needs to execute query for all objects matching
  the current navigation filter settings. It then
  needs to render these using a recursive page
  template. Notice that the action pointing to the
  sitemap is portal_url/sitemap.
• At first sight, this is sub-optimal, because the
  sitemap can't know the context the user was in
  before clicking the link, and thus can't put a
  "you are here" marker in the sitemap.
• But if the path were object_url/sitemap, then
  the sitemap on /foo would be different from the
  sitemap at /bar. Any cache for /foo/sitemap would
  be completely separate from /bar/sitemap even
  though 98 of the information on those two pages
  would be the same.
• Worse, when Google comes to index the site it
  will spider a /sitemap for each and every page,
  which may bring your site to a grinding halt from
  executing too many queries.