[Catalyst] How to de-serialize json?

[Bill Moseley]

On Sat, Jan 23, 2010 at 1:40 PM, J. Shirley <jshirley at gmail.com> wrote:

>
>
> If I assume that decoding is synonymous with de-serialization, it
> makes more sense.  At first thought, I just don't think they're that
> similar, though.  Maybe in implementations (comparing JSON to HTTP
> POST parameters) it is, but in the case of HTTP::Body decoding a
> mime64-encoded JPEG, it isn't at all.
>


With a jpeg I assume the content type would be form-data (that included an
upload in the form) where the file ends up in $req->uploads, not as a
request parameter.

I find decoding requests analogous to Views.  In my apps controllers take
input (params, arguments and uploads) and the result is data in the stash.
 Then the View has the job of serializing (normally to HTML via template,
but no reason it can't be JSON or anything else).  In fact I have many
controller actions that are used for both normal full-page HTTP requests and
AJAX requests.  So, similar to how the controller action does not know or
care what view is going to be used, the controller action doesn't know or
care how the request is serialized over the wire.  That's how I picture it.



>
> >From a behavior standpoint, having a POST/PUT'd JSON segment that ends
> up in ->params would be maddening to me.  They aren't parameters, not
> even in the loosest of the RFC interpretations.
>

I'm trying to understand that point of view.  Why is that maddening?  If you
have a request serialized as json then $req->parameters would go unused and
instead have the deserialzed request end up some place else, say as
$req->data?

I have an XMLRPC API to an application.  I implemented it by creating an
HTTP::Body subclass that parses the XMLRPC XML body.  The <method> ends up
mapped to an action, the <params> ends up as body parameters, and <base64>
elements end up as uploads.  As a result existing controller actions can be
used for both XMLRPC request and for normal web requests.  All I have to do
to expose the action in the API is add  XMLRPC( $method_name ) as a action
attribute.

Catalyst::Engine hard-codes HTTP::Body.  I think it would be more flexible
if the body parser class could be a config option (to allow easy
sub-classing), -- similar to how the request class can be defined -- but
it's not that difficult to set up now.   Just have to add the content type
to  %HTTP::Body::TYPES.

Thanks for your comments, I appreciate the feedback.


-- =

Bill Moseley
moseley at hank.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20100123/6835d=
284/attachment.htm