Developer's Guide

Add a method to the relevant class that assembles and delivers your data. In this case, you'd probably add a method to the Products.ZenModel.Device.Device class that walks components under self and generates an event pill for each. We'll call it getComponentList. If your method should logically be broken up into several methods, for organization or otherwise, you'll add those to the class as well, or find a way to use nested functions.

Create a page template that calls the method and renders the data. Your template would be, say, ZenModel/skins/zenmodel/viewDeviceComponents.pt. Surrounding the content block, you'd have something like:

<tal:block tal:define="componentdata here/getComponentList">...</tal:block>

Link to your template. Either by adding a tab to the Device class, or by dropping a link in another template, you're going to point to a URL that describes a Device instance and your template:

<a tal:attributes="href string:${here/absolute_url_path}/viewDeviceComponents">
      Component List</a>

Create a BrowserView class to contain logic and load the template. Instead of inflating model classes with view methods, make yourself a BrowserView, which will adapt the context to add logic you need to render the template. That is, when a view is the result of traversal, the view class will be instantiated, passing the context into the constructor (it will be available on the view instance as self.context; the request object will be self.request).

You'll put something like this in ZenModel/browser/DeviceViews.py (browser is a convention):

from Products.Five.browser import BrowserView
from Products.Five.pagetemplatefile import ViewPageTemplateFile

class ComponentListView(BrowserView):

    __call__ = ViewPageTemplateFile('viewDeviceComponents.pt')

    def getComponentList(self):
        ... do things with self.context and self.request ...

BrowserViews are called when they're the result of a traversal, so that's your hook. ViewPageTemplateFile() is a callable, so the assignment is fine. If, instead of rendering a template, you just wanted to return some text (for example, JSON), you could do:

from Products.Five.browser import BrowserView
from Products.Five.pagetemplatefile import ViewPageTemplateFile

class ComponentListView(BrowserView):

    def __call__(self):
        ... do things with self.context and self.request ...
        return results

Create a page template that calls the method and renders the data. This is the same as the Zope 2 way, except for one key difference: view is now a global, and that's how you can access your custom method (here is still available and still refers to the context, just as before).

    <tal:block tal:define="componentdata view/getComponentList">
      ...
    </tal:block>

Another difference is that you don't render the template by traversing to a template against a context; instead, you traverse to a BrowserView, which knows which template to use. This is great, especially when you want to use the same template for radically different contexts; as long as you have two BrowserViews that know how to provide the methods the template wants, you're good.

Wire everything up with ZCML. This is where most people start scoffing. It's okay. It actually makes sense.

So you have a view, but you don't have a way to call that view; there isn't a URL that will resolve to an instance of your BrowserView. To fix that, you register the view.

When Zope starts up, it looks inside every Product for a file called configure.zcml. In Zenoss, most Products don't have one (though some do now). You can do a bunch of stuff with these, but we're going to ignore everything except registration of views.

You would, in this case, modify Products/ZenModel/browser/configure.zcml (because Device is in ZenModel; it doesn't actually matter where you register the view, but you should try to keep Products pluggable), adding the registration of your view:

          <browser:page
              for="Products.ZenModel.Device.Device"
              name="componentlist"
              class=".DeviceViews.ComponentListView"
              permission="zope2.View"
              />

Notice that your view is defined as being applicable only to instances of the Device class. Were you to attempt to call componentlist against an IpInterface instance, for example, you'd get a 404 -- not so if componentlist were a mere template. Also notice the relative import in the class attribute; .DeviceViews will look for the DeviceViews module in the current package, that is, ZenModel.browser.