Re: Tentative Schedule for 1.4

[John Locke <..hidden..>]

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