Re: Pyro-core Digest, Vol 87, Issue 1

On 5-7-2014 15:45, Plamen Dimitrov wrote:

> This is indeed quite much but I prefer to minimize modification of the original code. In
> order for the method above to work I need the get() method to exist on the remote
> object. This is indeed the case here, but I was also wondering if I could use similar
> approach to access remote attributes. Is there any way to surpass the Proxy object
> methods by let's say call something of the kind
> 
> firefox._original_object.method_that_could_also_be_found_in_the_proxy_class
> 
> ?

Can't be done for attribute access. This is something that is not supported by Pyro4.
You can however enable DOTTEDNAMES which allows it to traverse a "nested" object such as
what you described, but again, this will only work if the final part is an actual method
call.
See https://pythonhosted.org/Pyro4/security.html#index-5
and the 'attributes' example that comes with Pyro


> I definitely need access to more than just the remote object's methods like its magic
> methods and attributes even if it is indirectly like above. Implementing methods
> especially for attributes would be a large modification of the original code on my side.
> Do you think this is possible? What else could I do?

Sorry, you'll have to create your own proxy subclasses then, so that the attributes are
known on the client side. Again, Pyro4 doesn't support remote attribute access. The
mechanism to transparently translate a __getattr__ to a remote getattr if the name isn't
a *method* is just not there right now.


Irmen



------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft