On 13 August 2013 16:37, John Napiorkowski <[email protected]> wrote:
[...]
> The main issue that I see is that we have too many ways to do exactly the
> same thing (return JSON for AJAX endpoints) and no clear reason why any of
> them are better for a given purpose. Additionally, some of them are a bit
> verbose, and Catalyst already has reputation for being the long way to do
> simple things.
>
> However it does seem to me after we've all talked about it quite a bit that
> at this point there really doesn't seem to be a really exciting approach that
> would be useful (talking about a common way to handle the serialize / format
> stuff, like allowing res->body to take a ref and convert it to JSON or XML,
> etc.) At least in terms of something that belongs in Catalyst core. Why
> not lets pull that part out of the spec and make it a separate research
> project, and for now continue to let the community play with various
> approaches. I think there appears to be less controversy on the request
> side, in terms of building in alternative content parsing, and possibly a
> first go at subroutine attribute content type negotiation.
>
> Any thoughts on the request side of the proposal?
Ultimately, from my own experience of doing XML / JSON /
whatever-encoded requests and responses, is:
ยท I needed to be able to specify, *once I'd dispatched the request* to
be able to
- deserialise the request
- set a flag in the request or response to indicate that the latter
needed serialising
Being able to put an attribute on an action, e.g.
: DeserializeUsing(method_name) SerializeResponseUsing(other_method_name)
would be kinda cool, although I settled for pushing callbacks onto a
list in $c->stash for the latter, and deserialising in part of a chain
that was shared by all the requests that needed it. Sometimes you want
a handful of AJAXy actions in amongst mostly-normal templated HTML
page, though, so being able to label just one or two actions in a
controller that way would be neat. All quite unnecessary, can do it by
hand where needed, etc., but handy.
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
