Go to the latest version of this document.
search in docstrings

Search bar offers the following options:

- Term presence. The below example searches for documents that must contain “foo”, might contain “bar” and must not contain “baz”: `+foo bar -baz`
- Wildcards. The below example searches for documents with words beginning with “foo”: `foo*`
- Search in specific fields. The following search matches all objects in "twisted.mail" that matches “search”: `+qname:twisted.mail.* +search`

  Possible fields: 'name', 'qname' (fully qualified name), 'docstring', and 'kind'. Last two fields are only applicable if "search in docstrings" is enabled.

- Fuzzy matches. The following search matches all documents that have a word within 1 edit distance of “foo”: `foo~1`

Results provided by Lunr.js

# ``twisted`.`spread`.`pb`.`ViewPoint``

class documentation

`class ViewPoint(Referenceable): (source)`

View In Hierarchy

I act as an indirect reference to an object accessed through a `pb.IPerspective`.

Simply put, I combine an object with a perspective so that when a peer calls methods on the object I refer to, the method will be invoked with that perspective as a first argument, so that it can know who is calling it.

While `Viewable` objects will be converted to ViewPoints by default when they are returned from or sent as arguments to a remote method, any object may be manually proxied as well. (XXX: Now that this class is no longer named `Proxy`, this is the only occurrence of the term 'proxied' in this docstring, and may be unclear.)

This can be useful when dealing with `pb.IPerspective`s, `Copyable`s, and `Cacheable`s. It is legal to implement a method as such on a perspective:

     | def perspective_getViewPointForOther(self, name):
     |     defr = self.service.getPerspectiveRequest(name)
     |     defr.addCallbacks(lambda x, self=self: ViewPoint(self, x), log.msg)
     |     return defr

This will allow you to have references to Perspective objects in two different ways. One is through the initial 'attach' call -- each peer will have a `pb.RemoteReference` to their perspective directly. The other is through this method; each peer can get a `pb.RemoteReference` to all other perspectives in the service; but that `pb.RemoteReference` will be to a `ViewPoint`, not directly to the object.

The practical offshoot of this is that you can implement 2 varieties of remotely callable methods on this Perspective; view_xxx and `perspective_xxx`. `view_xxx` methods will follow the rules for ViewPoint methods (see ViewPoint.`remoteMessageReceived`), and `perspective_xxx` methods will follow the rules for Perspective methods.

Method | `__init__` | Initialize me with a Perspective and an Object.
Method | `processUniqueID` | Return an ID unique to a proxy for this perspective+object combination.
Method | `remoteMessageReceived` | A remote message has been received. Dispatch it appropriately.
Instance Variable | `object` | Undocumented
Instance Variable | `perspective` | I am an object sent remotely as a direct reference.

Inherited from `Referenceable`:

Method | `jellyFor` | (internal)

Inherited from `Jellyable` (via `Referenceable`, `Serializable`):

Method | `getStateFor` | Undocumented

def __init__(self, perspective, object): (source)

Initialize me with a Perspective and an Object.

def processUniqueID(self): (source)
overrides `twisted.spread.pb.Serializable.processUniqueID`

Return an ID unique to a proxy for this perspective+object combination.

def remoteMessageReceived(self, broker, message, args, kw): (source)
overrides `twisted.spread.pb.Referenceable.remoteMessageReceived`

A remote message has been received. Dispatch it appropriately.

The default implementation is to dispatch to a method called '`view_messagename`' to my Object and call it on my object with the same arguments, modified by inserting my Perspective as the first argument.

object = (source)

Undocumented

perspective = (source)
overrides `twisted.spread.pb.Referenceable.perspective`

I am an object sent remotely as a direct reference.

When one of my subclasses is sent as an argument to or returned from a remote method call, I will be serialized by default as a direct reference.

This means that the peer will be able to call methods on me; a method call xxx() from my peer will be resolved to methods of the name remote_xxx.