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
- BEFORE_CREATING_ENVELOPE
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(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/suds