Skip Menu |

This queue is for tickets about the Catalyst-Controller-DBIC-API CPAN distribution.

Report information
The Basics
Id: 54430
Status: rejected
Priority: 0/
Queue: Catalyst-Controller-DBIC-API
People
Owner: Nobody in particular
Requestors: onken [...] netcubed.de
Cc:
AdminCc:
Bug Information
Severity: Normal
Broken in: 2.001001
Fixed in: (no value)

History Show all quoted text
  Mon Feb 08 22:15:16 2010 onken [...] netcubed.de - Ticket created
Subject: Allow $req->data to be an arrayref
Right now DBIC::API allows two kinds of json objects {list:[{first: 'me'}]} and {first: 'me'} It would be nice if you could also add [{first: 'me'}] which would make requests like [{first: 'me'}, {first: 'and me'}] possible. Regards, moritz
  Mon Feb 08 23:12:22 2010 nperez [...] cpan.org - Correspondence added
On Mon Feb 08 22:15:16 2010, PERLER wrote: Show quoted text
> Right now DBIC::API allows two kinds of json objects > > {list:[{first: 'me'}]} > > and {first: 'me'} > > It would be nice if you could also add > > [{first: 'me'}] > > which would make requests like > > > [{first: 'me'}, {first: 'and me'}] possible. > > Regards, > > moritz
Is there any particular reason you can't do {data:[ {first: 'me'}, {first: 'me too'} ] } ? The single hashref syntax is really a backward compat thing. All of my use cases actually do the proper {data: [...]} thing (and in fact, coerce a single hashref, with or without the "data" key into an ArrayRef[HashRef]). Making the data explicitly available via the data_root key is a much cleaner implementation and eventually, I'd like to do away with the raw hashref. If you have a compelling reason to support this other syntax, I'll consider it, but if you really want to support it on your own, the logic for handling all of that is inside DBIC::API/object and it is very easy for you to override the method via Moose
  Mon Feb 08 23:12:23 2010 The RT System itself - Status changed from 'new' to 'open'
  Tue Feb 09 02:34:37 2010 onken [...] netcubed.de - Correspondence added
On Mon Feb 08 23:12:22 2010, NPEREZ wrote: Show quoted text
> On Mon Feb 08 22:15:16 2010, PERLER wrote:
> > Right now DBIC::API allows two kinds of json objects > > > > {list:[{first: 'me'}]} > > > > and {first: 'me'} > > > > It would be nice if you could also add > > > > [{first: 'me'}] > > > > which would make requests like > > > > > > [{first: 'me'}, {first: 'and me'}] possible. > > > > Regards, > > > > moritz
> > Is there any particular reason you can't do {data:[ {first: 'me'}, > {first: 'me too'} ] } ? > > The single hashref syntax is really a backward compat thing. All of my > use cases actually do the proper {data: [...]} thing (and in fact, > coerce a single hashref, with or without the "data" key into an > ArrayRef[HashRef]). > > Making the data explicitly available via the data_root key is a much > cleaner implementation and eventually, I'd like to do away with the raw > hashref. > > If you have a compelling reason to support this other syntax, I'll > consider it, but if you really want to support it on your own, the logic > for handling all of that is inside DBIC::API/object and it is very easy > for you to override the method via Moose
The use case is, that Ext.Direct (part of ExtJS) makes this kind of requests. I'd either have to override ExtJS or this module to make it work. I think it wouldn't break any backwards compat as far as I can tell from the code. regards, moritz
  Thu Jan 13 13:09:54 2011 abraxxa [...] cpan.org - Correspondence added
See comment of Nick Perez. Also CatalystX::ExtJS seems to fullfil the requirement.
  Thu Jan 13 13:09:55 2011 abraxxa [...] cpan.org - Status changed from 'open' to 'rejected'