Okay, this is one of those times to ask the list rather than try and work it out... :) The HOWTO at http://www.zope.org/Members/Amos/XML-RPC assures me that methods like objectIds should be accessible via http access, as in http://mysite.com/Container/objectIds, yet this patently does not work (at least in my site), even with appropriate authentication provided in the URL. The result is the notorious "object does not have a docstring" error. At least one comment by Dieter (http://article.gmane.org/gmane.comp.web.zope.plone.archetypes.devel/2800) suggests that this error is actually a "not found" response, and *also* appears to suggest that actions methods are not callable, unless wrapped (though I may well have understood the meaning of the term "action id"). The article http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&c2coff=1&selm=b1tu76%24ht 6%241%40norfair.nerim.net also states that objectIds isn't accessible via xmlrpc and needs a wrapper. Whether via plain old http or xmlrpc, I can't get methods like objectIds to work. I can, of course, use the ZMI manage_ methods via http to do what I need, but that's not amazingly convenient, since any errors are delivered back in HTML intended for a human, and I need to use tricks like modifying the standard_error_message template so that I can detect a given string and spot that an error's being flagged. There must be something I'm missing here... ben ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
Ben Last (Zope) wrote:
Okay, this is one of those times to ask the list rather than try and work it out... :)
The HOWTO at http://www.zope.org/Members/Amos/XML-RPC assures me that methods like objectIds should be accessible via http access, as in http://mysite.com/Container/objectIds, yet this patently does not work (at least in my site), even with appropriate authentication provided in the URL. The result is the notorious "object does not have a docstring" error. At least one comment by Dieter (http://article.gmane.org/gmane.comp.web.zope.plone.archetypes.devel/2800) suggests that this error is actually a "not found" response, and *also* appears to suggest that actions methods are not callable, unless wrapped (though I may well have understood the meaning of the term "action id").
The article http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&c2coff=1&selm=b1tu76%24ht 6%241%40norfair.nerim.net also states that objectIds isn't accessible via xmlrpc and needs a wrapper.
Whether via plain old http or xmlrpc, I can't get methods like objectIds to work. I can, of course, use the ZMI manage_ methods via http to do what I need, but that's not amazingly convenient, since any errors are delivered back in HTML intended for a human, and I need to use tricks like modifying the standard_error_message template so that I can detect a given string and spot that an error's being flagged.
There must be something I'm missing here...
ben
firstly: try it with a script as mediator... ## Script (Python) "objectids" ##bind container=container ##bind context=context ##bind namespace=_ ##bind script=script ##bind subpath=traverse_subpath ##parameters= ##title=objectids ## return obj.objectIds() call that script through xmlrpc
______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Michael Haubenwallner wrote:
firstly: try it with a script as mediator...
## Script (Python) "objectids" ##bind container=container ##bind context=context ##bind namespace=_ ##bind script=script ##bind subpath=traverse_subpath ##parameters= ##title=objectids ##
return obj.objectIds()
call that script through xmlrpc
sorry - missed the context... ## Script (Python) "objectids" ##bind container=container ##bind context=context ##bind namespace=_ ##bind script=script ##bind subpath=traverse_subpath ##parameters= ##title=objectids ## obj = context.aq_parent return obj.objectIds()
From Michael Haubenwallner firstly: try it with a script as mediator... I know that works; this is not a problem. I'm more interested in the general case of how one calls Zope methods via rpc, or even via http. I can achieve what I need to (and have done) by using the manage_ methods that are invoked by ZMI, but that's really pretty ugly, since one has to parse the HTML response to determine success or failure.
If I have to add wrappers for every method I want to call, I end up doing a lot of Zope programming just to make it easy for me to drive it via http or xmlrpc calls, and I'd hoped to avoid that by using Zope. I mean, even an ASP or PHP website can have specific scripts added to manage it... :) regards ben ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
Ben Last (Zope) wrote:
From Michael Haubenwallner firstly: try it with a script as mediator...
I know that works; this is not a problem. I'm more interested in the general case of how one calls Zope methods via rpc, or even via http. I can achieve what I need to (and have done) by using the manage_ methods that are invoked by ZMI, but that's really pretty ugly, since one has to parse the HTML response to determine success or failure.
If I have to add wrappers for every method I want to call, I end up doing a lot of Zope programming just to make it easy for me to drive it via http or xmlrpc calls, and I'd hoped to avoid that by using Zope. I mean, even an ASP or PHP website can have specific scripts added to manage it... :)
i think your wrong here. please have a look at Boa Constructor (http://boa-constructor.sourceforge.net/) the distribution includes a set of methods to access a zope server by xmlrpc from boa-constructor. -- michael
Michael Haubenwallner i think your wrong here. please have a look at Boa Constructor (http://boa-constructor.sourceforge.net/) the distribution includes a set of methods to access a zope server by xmlrpc from boa-constructor. It does - the "zoa" stuff that it installs in the root of a Zope instance. This is a set of wrapper scripts. I was trying to avoid having to write a set of wrapper scripts. Mea culpa - I think my earlier email was not clear.
I guess I misunderstood when I was evaluating Zope; without wrapping many of the management methods, it's equivalent to doing remote operations by screen-scraping. I'm not trying to be controversial or to annoy here; it's just that I understood one of the *big* advantages of Zope was that it could be managed (and by this I mean items uploaded, deleted, renamed, listed, etc) very easily using http. It looks to me as though that's true only for given values of "easily" - if one wants to parse HTML responses to detect errors and write wrapper scripts to do much of the work, then it's possible. regards, ben ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
From: "Ben Last (Zope)" <zope@benlast.com>
Whether via plain old http or xmlrpc, I can't get methods like objectIds to work. I can, of course, use the ZMI manage_ methods via http to do what I need, but that's not amazingly convenient, since any errors are delivered back in HTML intended for a human, and I need to use tricks like modifying the standard_error_message template so that I can detect a given string and spot that an error's being flagged.
We do this quite a lot. We use cURL (or an equivalent http utility) to form an http request which consists of the target method within the zope site and passes zero or more parameters. The target zope method is a standard dtml or python script method with only one difference: it does not return html code it returns standard ascii. This is done by eliminating any html in the method (ie. don't use standard_html_header or any other kind of html header). Errors are trapped using the try/except statements and error feedback is placed into string/list variables which are returned to the calling http process by simply: <dtml-var "_.str(listitem)"> (this causes an ascii version of the list variable to be returned). This process is very simple to implement. HTH Jonathan
From: Small Business Services [mailto:toolkit@magma.ca] We do this quite a lot. Thanks Jonathan, that sounds like a very useful set of scripts - are you able to post any examples? regards ben
______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
From: "Ben Last (Zope)" <zope@benlast.com>
From: Small Business Services [mailto:toolkit@magma.ca] We do this quite a lot. Thanks Jonathan, that sounds like a very useful set of scripts - are you able to post any examples?
The dtml methods/python scripts are standard, other than the removal of any use of html (eg. no <html> <body> tags or anything that sets html tags, such as standard_html_header/footer or standard_error_message. Here is an example of some python code to trap errors (from an external method): import sys, traceback def somefunc(self): try: <your code here> except: etype = sys.exc_info()[0] evalue = sys.exc_info()[1] etb = traceback.extract_tb(sys.exc_info()[2]) return str([etype, evalue, etb]) If an error is encountered this returns a string version of the list containing the relevant error info. The dtml method that calls this routine would have a simple statement: <dtml-var somefunc> In the case of an error a string would be returned to the calling http routine which contains the error info (the calling http routine would need to parse the string to get at the error list items). We use cURL from either perl or C++ routines (you can use a command line call to cURL or the cURL C++ library routines), so I don't know if code examples from these would be of any use. HTH Jonathan
Hi Ben, objectIds is definitly callable through XML-RPC. I tried this myself yesterday. If I understand you right, your problem is not that Zope doesn't support XML-RPC, but that the Zope management is not accessible through XML-RPC? In that case, I believe, you could make a huge contribution to the community. As far as I know, Zope management is not accessible through XML-RPC. Would be great if someone tackle the problem, wouldn't it? :) /Ulrich
Ulrich - it definitely fails for me, via xmlrpc. What version are you running? I'm using 2.7.something on Linux... ben -----Original Message----- From: Ulrich Wisser [mailto:ulrich.wisser@relevanttraffic.se] Sent: 11 June 2004 11:36 To: Ben Last (Zope) Cc: Small Business Services; ZopeList Subject: Re: [Zope] External http access. Hi Ben, objectIds is definitly callable through XML-RPC. I tried this myself yesterday. If I understand you right, your problem is not that Zope doesn't support XML-RPC, but that the Zope management is not accessible through XML-RPC? In that case, I believe, you could make a huge contribution to the community. As far as I know, Zope management is not accessible through XML-RPC. Would be great if someone tackle the problem, wouldn't it? :) /Ulrich
Ulrich Wisser wrote at 2004-6-11 12:36 +0200:
objectIds is definitly callable through XML-RPC. I tried this myself yesterday.
If I understand you right, your problem is not that Zope doesn't support XML-RPC, but that the Zope management is not accessible through XML-RPC?
In that case, I believe, you could make a huge contribution to the community. As far as I know, Zope management is not accessible through XML-RPC. Would be great if someone tackle the problem, wouldn't it? :)
The only reason why the ZMI is difficult to use with XML-RPC is that the management functions like to perform redirects and return HTML responses. Just create small wrappers for the functions you need that call these functions without passing in "REQUEST". -- Dieter
From: Dieter Maurer [mailto:dieter@handshake.de]
The only reason why the ZMI is difficult to use with XML-RPC is that the management functions like to perform redirects and return HTML responses. But this is sufficient to make it very difficult; parsing the HTML reply is non-trivial; though a useful trick is to embed a fixed string in the standard_error_message template that one can detect. Unfortunately, not every manage_ function uses the standard error template for all errors.
Using xmlrpc is sufficiently simpler than using urllib (to call ZMI methods) that it approaches having one line per ZMI request, which makes for simple code, which makes for maintainable code. That, to me, is worth spending a day's effort on, so... What I'm going to do is to look into building a generic set of wrappers for the basic functions which will provide a simple error status reply, as much as is possible. Then I'll provide these to anyone who wants them. If such a thing has already been built, please let me know! regards ben
participants (5)
-
Ben Last (Zope) -
Dieter Maurer -
Michael Haubenwallner -
Small Business Services -
Ulrich Wisser