On 9/13/06, Rob Kinyon <[EMAIL PROTECTED]> wrote:
> What's the major benefit over:
>
> my $json = JSON::Syck::Dump({ $row->get_columns });
>
> If there is, then great! But, I'm not sure how a component really
> gains over what seems to be a one-liner.
Relationships are also dumped.
So if you've got A which has_many B, you'll get something like:
A = {
A_field1: 'value',
A_field2: 'value',
// etc
relationship: [
{ B_field1: 'value', B_field2: 'value' },
{ B_field1: 'value', B_field2: 'value' }
]
}
In fact, this sort of thing was my main motivation behind the
development of this component, since I've got arbitrarily nested
relationships (in a parent-child scheme) which I needed available as
JSON. In fact, there's a specific feature for this use case in the
component.
Another nice thing is that it can easily acommodate having "custom
renderers" for columns based on column_type or whatever. I actually
tried implementing automatic DateTime -> JS Date object conversion,
but I couldn't coerce JSON::Syck to drop the quotes. If I manage to
get this one working, it'll be "the killer feature" (at least for me).
;-)
There's another silly feature that simplifies the generic use case:
the possibility to define certain columns as being hidden from the
JSON serialization by default. This is useful when you're serializing
e.g. user objects but don't fields such as the user password to be
serialized. Granted, this is one is all about lazyness.
And last, but not least: it looks a lot better to just call [%
row.as_json %] from TT than any other method I could think of. In my
book, syntatic sugar is important.
-Nilson Santos F. Jr.
_______________________________________________
List: http://lists.rawmode.org/cgi-bin/mailman/listinfo/dbix-class
Wiki: http://dbix-class.shadowcatsystems.co.uk/
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class/
Searchable Archive: http://www.mail-archive.com/dbix-class@lists.rawmode.org/
