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”:
Search in specific fields. The following search matches all objects
in "twisted.mail" that matches “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”:
Results provided by Lunr.js
I act as an indirect reference to an object accessed through a
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.
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.)
| 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.
||Initialize me with a Perspective and an Object.|
||Return an ID unique to a proxy for this perspective+object combination.|
||A remote message has been received. Dispatch it appropriately.|
||I am an object sent remotely as a direct reference.|
Return an ID unique to a proxy for this perspective+object combination.
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.
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.