In Dream 2.x, service feature implementations are pre-defined in their parameter list.  This document proposes a backwards-compatible way to augment the definition capabilities of service features.  The benefits of the new notation are multiple.  First, the expected arguments are readily readable from the method signature.  Second, it's easier to test these methods without requiring a complete service instantiation.

    The proposed change relies heavily on convention over configuration.  This provides a more streamlined programming experience without impacting readability.

    Samples

    Following are some examples of how features would be defined with the new conventions.

    Backwards Compatible

    [DreamFeature("PUT:feature/{key1}/{key2}")]
    public Yield PutFeature(
        DreamContext context, 
        DreamMessage message, 
        Result<DreamMessage> response
    ) {
    
        // convert request body into an XML document
        XDoc doc = message.ToDocument();
    
        // read path parameters
        string key1 = context.GetParam("key1");
        string key2 = context.GetParam("key2");
    
        // read query parameter from context
        string query = context.GetParam("q", null);
    
        // rest of the implementation
    }

    Async Feature Definition

    [DreamFeature("PUT:feature/{key1}/{key2}")]
    public Yield PutFeature(
        XDoc body, 
        string key1, 
        string key2, 
        string q, 
        Result<DreamMessage> response
    ) {
        // rest of the implementation
    }

    Sync Feature Definition

    [DreamFeature("PUT:feature/{key1}/{key2}")]
    public DreamMessage PutFeature(
        XDoc body, 
        string key1, 
        string key2, 
        string q
    ) {
        // rest of the implementation
    }

    Type & Name Mapping for Feature Parameters

    Type Name Meaning
    string verb request verb (e.g. GET, PUT, ...)
    string[] path matched feature path (e.g. [ "feature", "key1", "key2" ])
    XUri * request URI (e.g. http://server/service/feature/key1/key2)
    DreamCookie {cookie_name} value of cookie with name cookie_name (null if missing)
    DreamHeader {header_name} value of header with name header_name (null if missing)
    string {path_param_name} value of path parameter with name path_param_name
    string {query_param_name} value of query parameter with name query_param_name (null if missing)
    string[] {query_param_name} array of values of query parameters with name query_param_name (empty array if missing)
    DreamMessage * full request message
    Stream body body of the request as stream
    string body body of the request as string
    XDoc body body of the request as XML document
    byte[] body body of the request as byte array
    DreamContext * context object for the request
    Result<DreamMessage> * async result object for response

    Notes

    • "verb" and "path" take precedence of similarly named parameters.  So don't use these terms for your parameters!
    • Path parameters never return a null value since they are required in the signature.  However, query parameters are not guaranteed to exist.  As with DreamContext.GetParam(), path parameters take precedence over query parameters.
    Tag page
    You must login to post a comment.

    Copyright © 2011 MindTouch, Inc. Powered by