[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Tentative Schedule for 1.4

On 02/25/2012 05:12 PM, Chris Travers wrote:
On Sat, Feb 25, 2012 at 1:30 PM, John Locke<..hidden..>  wrote:

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)

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.

John Locke