I needed to write the following method:
# override the RDBO::Helpers method
sub column_values_as_json_overrides
{
my $self = shift @_;
my $select = shift @_;
# local $self->{STATE_SAVING()} = 1;
my $data = Rose::DB::Object::Helpers::column_value_pairs($self);
my %out = ();
foreach (keys %$select)
{
$out{$_} = (defined $select->{$_}) ? $select->{$_} : $data->{$_};
}
return JSON::Syck::Dump(\%out);
}
which works exactly like RDBO::Helpers::column_values_as_json, except
you have to explicitly say which columns can be shown, and you can add
arbitrary fields or override column values. For example, given $object
with 'data' and 'data2' columns:
$object->column_values_as_json_overrides( { a => "b", data => undef, data2 =>
"override!" } );
will return
{"a":"b", "data": "DATA VALUE FROM DATABASE", "data2": "override!"}
I think this is much better security, and this method would make sense
in RDBO::Helpers. If $select is made optional above, which I didn't
bother doing, it's backwards compatible with the old
column_values_as_json method. I don't know why the STATE_SAVING call
fails on my call, and I don't really use mixins so I didn't debug it
because it worked all right for me.
The same optional parameter could be used for the column_values_as_yaml
and init_from_{yaml,json} methods.
If the value given in the $select hash for a column is a function ref,
it could be called on the available data. I didn't implement that
because I didn't need it, but it would make sense for some cases where
you want your JSON to be a specific variation of the real data.
Ted
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Rose-db-object mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rose-db-object
