热搜: 活动 交友 discuz
查看: 4809|回复: 0


发表于 2011-10-22 07:40:34 | 显示全部楼层 |阅读模式
The portal_skins tool from CMF relies on Zope 2 Acquisition. In Zope 3 this feature is dropped because it allows a wide range of dirty tricks, which makes code work like magic. Another reason to not want acquisition is performance. While acquiring an attribute the zope security machinery has to be used.
In Zope 3 Templates are connected to a browser view for a given context with ZCML. In addition those templates are guarded with a permission.

  1. <configure xmlns="" xmlns:browser="">
  2. <browser:page
  3.  for="Products.plonehrm.interfaces.worklocation.IWorkLocation"
  4.  name="worklocationview"
  5.  class=".worklocation.WorkLocationView"
  6.  permission="zope.Public"
  7.  template=""
  8.  allowed_interface=".interfaces.IWorkLocationView" />
  9. </configure>

for: The for directive specifies which interface the context should provide to allow calling the view. In this example the view can only be called on a content object that provides IWorkLocation.
name: This is the name that can be used in the URL to call the view.
class: This is the class which provides the BrowserView class for the template. Within the template the methods of this class are available through the view variable e.g.:
tal:define="mytitle view/Title"permission: This directive allows you to hook up the Zope security to guard access to the template. zope.permname calls the zope3 machinery. Within Five also zope2.permname and cmf.permname are available, so when working with Zope 2 we should use e.g. cmf.ModifyPortalContent
template: this directive allows you to hook your template to the view.
allowed_interface: this directive is another type of security. Normally python permits even calls to private methods, by defining an Interface here, you strictly provide the publically available methods defined in the interface.
Typically all HTML templates are placed in a package named browser because it handles calls from a web browser. When handling different types of interaction you should put those in a separate package e.g. ftp.
When you create a browser view, make sure that it doesn’t have the same name as a template that can be reached via acquisition. If you ignore this advise, you might run into a situation where sometimes the page template if found and in other cases the browser view.
Images, css and javascriptNOTE: by putting images in a skins folder and providing a .metadata will allowcachefu to add correct headers. Z3 resources are not picked up yet. css, js are kss are no problem since they are served by the resource registry.In Zope 2 we used to go through all images into a skin and rely on acquisitioning of the portal_skins tool to find those files. In Zope 3 we call these files resources and we need to explicitly make these files available with ZCML.

  1. <configure xmlns="" xmlns:browser="">
  2.  <!-- Individual Resources -->
  3.  <browser:resource name="zest.css" file="zest.css" />
  4.  <!-- Entire Directory with resources -->
  5.  <browser:resourceDirectory name="images" directory="images" />
  6. </configure>

The first option is used for publishing a specific resource, the second option is comparable to the old portal_skins skins folder.
Resources are published through a special namespace in Zope 3: http://localhost/++resource++resourcename

  1. http://localhost/++resource++zest.css
  2. http://localhost/++resource++images/image1.jpg


使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册


QQ|小黑屋|Archiver|手机版|Plone技术资料 ( 湘ICP备14006519号-1 )

GMT+8, 2019-11-21 14:56 , Processed in 0.047194 second(s), 18 queries , Gzip On.

Powered by Plone! X3.4

© 2001-2019

快速回复 返回顶部 返回列表