On 02/25/2012 05:12 PM, Chris Travers wrote: > On Sat, Feb 25, 2012 at 1:30 PM, John Locke<m...@freelock.com> wrote: > > <snip> >> I'd say the main difference is taking the standard centralized stuff one >> step further than you've outlined, doing the URL parsing and establishing >> conventions before handing off to individual web service controllers. >> >> I've also found it useful to have separate request and response objects, >> though at the moment I don't recall why. And of course have a different >> class for each type of response and request -- XML, JSON, HTML, etc. -- that >> implement standard methods that the framework can call regardless of type. > > Ok. We'd need to map those out. Any specific ideas?
$request -> method $request -> headers (hash array) $request -> data (hash array of body of request, deserialized from json/xml/form/etc -- unless there's some easy way to convert to a native LSMB data object, with data deserialized from request?) $request -> raw (unprocessed body of request) $request -> path $request -> params (hash array of GET parameter) $request -> page (hash of start, count for index queries) Generally would route the request to a controller class and method based either on GET params or on path/method (and usually a scheme for both, with one taking precedence). In the past I've used: GET /(classname) -> $class->index GET /(classname)/(id) -> $class->get(id) PUT /(classname)/(id) -> $class->update(id) POST /(classname) -> $class->create DELETE /(classname)/(id) -> $class->delete(id) POST /(classname)/(id)/(action) -> $class->callAction(action, id) ?view=(type) -> override content-type header to designate response type ?action=(action) -> call specific method on a controller class (generally go through some standard action method first to apply access control) ?module=(class) I've tended to create a base class for $response, and then extend that for each type. Then the controller can simply call a standard method on the object to deserialize as appropriate. $response -> type (xml, json, html, etc) $response -> data (hash array) $response -> headers $response -> status (e.g. 200 OK by default) $response -> page (hash of start, count of results returned, 'match' total number of rows matching an index query) $response -> error (if there's a problem, error message/code) ... something like that... In most cases, the individual controllers would only set data and the page properties. For errors, I would generally just throw an exception and have the exception handler set the error object on the response. The individual response class should set headers/status as appropriate for the standard being implemented. In one system I built, I used this same system for handling HTML pages as well as web services calls. This was using Smarty in PHP -- seems like Template Toolkit ought to work well for this as well... For that, I also had a $response->template where the controller could specify the HTML template to use, and methods for $response->assign, $response->assignSet to populate $response->data with variables as the page gets built... And then $response->render to serialize the output to the caller. Cheers, John Locke http://freelock.com ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
