On Friday 14 May 2010, Daniel Rodriguez elucidated thus:
Hi,
I have read the proposal and the initial comments and here below my
personal view.
-- Your plugin scheme is generic enough to try to handle everything,
but I think that different planes of execution are being mixed, and
even with the subclassing approach things can get mixed. I see the
following different planes:
- Initialization
- Loading
- Anything to do with invoking a SOAP method
Therefore there would be three different types of plugins.
To tackle such a problem and make things simple, instead of a plugin
object, the user of suds could insert callables at each defined
filter point like in this example:
myclient.filter.addcallable(SENDING, mycallable)
Using a callable enables passing functions or objects that define the
__call__ method, which adds a layer of generalization.
Each callable would then receive an object with at least the
following attributes:
- filterPoint (SENDING, LOADING, etc ...)
- data
One callable could handle more than one event if wished.
After all the above, let me say that the object approach is also good
enough for me and I would graciously accept it as a very nice
addition to suds.
I would anyhow add some more entry points:
- AFTER_PROCESSING_REPLY
XML text has been received, processed and converted to the response
object.
For whatever the reason, a plugin may choose to examine and/or change
the objects or the content of the objects
I'll agree to this. One of the projects I use (Salesforce Python
Toolkit) does some hacking to get "any" type responses converted from
single-item lists to strings. Putting this into a plugin would make
that hack more elegant.
Also, would allow a library wrapping suds to define what happens when an
object or reply is empty. From the HACKS file of the Salesforce Python
Toolkit:
- Partner WSDL calls return lists containing strings instead of
strings for <any/> elements
- This affects query(), queryAll(), queryMore(), retrieve(), and
search()
- Hack is to recursively iterate through the QueryResult object and
convert lists to strings
- Solution is for Suds to make the default type for anyType elements
configurable
- Suds with Partner and Enterprise WSDLs return an empty string when
no search() results found
- <result/> gets unmarshalled as '' instead of an empty SearchResult
- Hack is to return an empty SearchResult instead
- Solution is for Suds to check the XML and return SearchResult
With a hook like the above, it would move that "translation" code into
the suds call. It wouldn't eliminate the need to do those things, but
I think the flow would be cleaner.
- BEFORE_CREATING_ENVELOPE
Again, inspecting/changing the objects before they are converted to
the SOAP envelope may be wished.
Hmm...that would be cool too.
j
--
Joshua Kugler
Part-Time System Admin/Programmer
http://www.eeinternet.com
PGP Key:
http://pgp.mit.edu/ ID 0x73B13B6A