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:
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:
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:
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
Again, inspecting/changing the objects before they are converted to the SOAP envelope may be wished.

Nicely thought Jeff

Best regards

Daniel



On Thu, May 13, 2010 at 21:14, Jeff Ortel <jortel@redhat.com> wrote:


On 05/13/2010 01:31 PM, Joshua J. Kugler wrote:
On Thursday 13 May 2010, Jeff Ortel elucidated thus:
All,

Suds currently has (2) ways (hooks) for users to plug in
functionality (not including Transports).  First, is the schema
Doctor used to repair broken XSDs at runtime.  Second, is the
Binding.replyfilter used to alter the raw reply text.  In most cases,
the replyfilter is used to strip out undesirable characters before
sax parsing.

Recently, I needed to add a third hook to provide users with a means
to modify the outgoing soap envelope for certain edge cases.  Rather
then add yet another one-off hook, it seems better to add a more
general "plugin" facility.  Something more formal and extensible.
And so I did in 0.4 (beta).

Please see: https://fedorahosted.org/suds/wiki/Documentation#PLUGINS
and provide comments/suggestions including additional hooks.

Initial comments (just clarification, mostly).

Thanks for you comments Joshua.



 - Clarify in the docs exactly when the hooks get called

Excellent question!  I'll beef up the description for each hook on the wiki and epydocs.

, and what they contain.

Please see: http://jortel.fedorapeople.org/suds/doc/suds.plugin.Plugin-class.html


"After client is initialized."

OK, but what (loosely) has happend at that point?

Primarily, the WSDL object has been constructed and digested.

And before *what*?

Creation of:
 - The client.service object.
 - The client.factory object.
 - The ServiceDefinition ( which is what you see when you __str__() the client ).


What is the WSDL object?

The WSDL object isa wsdl.Definitions instance.

Please see: http://jortel.fedorapeople.org/suds/doc/suds.plugin.InitContext-class.html

The raw file (object)?

Nope.


The response from urllib2.urlopen()?

Nope.


 - Same for "loaded."  What does "loading" a WSDL or XSD entail?
Opening? Parsing?  It says "contains the document root." But:

loaded: "called before loading"..."contains document root"  Sounds like
it's called after something is loaded...the name is confusing.

Agreed.

The description needs to be reworded for clarity.  The term "load" refers to XML document loading which is basically open/download & SAX parsed into a DOM tree.  The 'context' argument isa plugin.LoadContext ( http://jortel.fedorapeople.org/suds/doc/suds.plugin.LoadContext-class.html ) which contains the loaded document root which is a sax.Element.



"Sending" and "received" seem clear enough.

Cool.



I'm sure I'll have more comments...those were the ones that struck me
first.

Great.  Thanks again!


j



_______________________________________________
suds mailing list
suds@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/suds