Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

separate wsgi logic from the soap parser #10

Closed
plq opened this issue Sep 27, 2010 · 11 comments
Closed

separate wsgi logic from the soap parser #10

plq opened this issue Sep 27, 2010 · 11 comments

Comments

@plq
Copy link
Member

plq commented Sep 27, 2010

in order to support transport mechanisms other than wsgi, the application logic must be separated from the wsgi logic.

@plq
Copy link
Member Author

plq commented Sep 29, 2010

this is also needed to transform soaplib from a soap server library to a generic soap parsing library.

@plq
Copy link
Member Author

plq commented Oct 1, 2010

the plan is to split wsgi.Application class in two. The part that will remain in wsgi module will obviously handle only the wsgi-related parts. everything else will be moved to the soaplib.Application class. it will have at least those public methods:

class Application(object):
    def parse_request(self,istr):
        """Takes an input stream containing ONE soap message.
        Returns the native python object.
        """
        pass

    def process_request(self,req_obj)
        """Takes the native request object.
        Returns the response to the request as a native python object
        """
        pass

    def push_response(self,ostr, resp_obj)
        """Pushes the native python object to the output stream as a 
        soap response
        """
        pass

    def get_wsdl(self):
        """Returns the application wsdl"""
        pass

@caustin
Copy link
Contributor

caustin commented Oct 5, 2010

This is great. I was sitting down this morning to plan work on this issues for the rest of the week. Also, I just did a pull master and I see that you've begun implementing the plan.

I'd really like to help with this but, I don't want to step on your toes.

Can you let me know where you'd prefer I'd pitch in on this? I've got plenty of time to work on this right now since soaplib looks pretty core to some of our new project's.

@plq
Copy link
Member Author

plq commented Oct 5, 2010

the interface has changed a bit, but it's essentially the same.

let me stabilize the api, then we'll talk.

@plq
Copy link
Member Author

plq commented Oct 5, 2010

i think i've got the basics to work. please hunt down bugs by writing tests / fixing the ones that fail.

this is the public api. what do you think?

class Application(object):
    def deserialize_soap(self, envelope_string, charset=None):
        """Takes a string containing ONE soap message.
        Returns the corresponding native python object, along with the request
        context

        Not meant to be overridden.
        """

    def process_request(self,ctx,req_obj):
        """Takes the native request object.
        Returns the response to the request as a native python object.

        Not meant to be overridden.
        """

    def serialize_soap(self, ctx, native_obj):
        """Pushes the native python object to the output stream as a
        soap response

        Not meant to be overridden.
        """

    def get_namespace_prefix(self, ns):
        """Returns the namespace prefix for the given namespace.
        Creates a new one automatically if it doesn't exist

        Not meant to be overridden.
        """

    def set_namespace_prefix(self, ns, pref):
        """Forces a namespace prefix on a namespace by either 
        creating it or moving the existing namespace to a new prefix

        Not meant to be overridden.
        """

    def get_name(self):
        """Returns service name that is seen in the name attribute
        of the definitions tag.

        Not meant to be overridden.
        """

    def get_tns(self):
        """Returns default namespace that is seen in the targetNamespace 
        attribute of the definitions tag.

        Not meant to be overridden.
        """

    def get_service_class(self, method_name):
        """This call maps method names to the services that will handle 
        them.

        Override this function to alter the method mappings. Just try
        not to get too crazy with regular expressions :)
        """

    def get_service(self, service, http_req_env=None):
        """The function that maps service classes to service instances.
        Overriding this function is useful in case e.g. you need to
        pass additional parameters to service constructors.
        """

    def get_schema(self):
        """Simple accessor method that caches application's xml schema,
        once generated.

        Not meant to be overridden.
        """

    def get_wsdl(self, url):
        """Simple accessor method that caches the wsdl of the
        application, once generated.

        Not meant to be overridden.
        """

    def validate_request(self, payload):
        """Method to be overriden to perform any sort of custom input
        validation.
        """

    def on_exception_object(self, exc):
        '''Called when the app throws an exception. (might be inside or
        outside the service call.

        @param the wsgi environment
        @param the fault object
        '''

    def on_exception_xml(self, fault_xml):
        '''Called when the app throws an exception. (might be inside or
        outside the service call.

        @param the wsgi environment
        @param the xml element containing the xml serialization of the
               fault
        '''

@caustin
Copy link
Contributor

caustin commented Oct 6, 2010

I thinks looks pretty good. I've started working on the tests today I should have a pull request for you tomorrow.

@plq
Copy link
Member Author

plq commented Oct 9, 2010

i'm not happy with two properties of the context object:

  1. it's created only by the serialize_soap call.
  2. it's in fact the service definition object.

here's how i think those issues should be addressed:

  1. separate context creation into its own public method: create_call_context
  2. the said function will return an RpcContext object that will have the service definition instance in a public instance variable called 'service'.

i haven't started implementing this yet. if anyone does, please drop a notice here so that we don't step on each other's toes.

@plq
Copy link
Member Author

plq commented Oct 9, 2010

the above is implemented in 6e41a83.

@plq
Copy link
Member Author

plq commented Oct 10, 2010

@plq
Copy link
Member Author

plq commented Oct 10, 2010

the next step is to implement alternative transports and patterns in order to validate current api and its implementation.

@plq
Copy link
Member Author

plq commented Oct 18, 2010

zeromq transport is implemented. i consider this job accomplished. closing issue.

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants