Catalyst-View-JSON

 view release on metacpan or  search on metacpan

README  view on Meta::CPAN

    in JSON format.

CONFIG VARIABLES
    allow_callback
        Flag to allow callbacks by adding "callback=function". Defaults to 0
        (doesn't allow callbacks). See "CALLBACKS" for details.

    callback_param
        Name of URI parameter to specify JSON callback function name.
        Defaults to "callback". Only effective when "allow_callback" is
        turned on.

    expose_stash
        Scalar, List or regular expression object, to specify which stash
        keys are exposed as a JSON response. Defaults to everything.
        Examples configuration:

          # use 'json_data' value as a data to return
          expose_stash => 'json_data',

          # only exposes keys 'foo' and 'bar'
          expose_stash => [ qw( foo bar ) ],

          # only exposes keys that matches with /^json_/
          expose_stash => qr/^json_/,

        Suppose you have data structure of the following.

          $c->stash->{foo} = [ 1, 2 ];
          $c->stash->{bar} = 2;

        By default, this view will return:

          {"foo":[1,2],"bar":2}

        When you set "expose_stash => [ 'foo' ]", it'll return

          {"foo":[1,2]}

        and in the case of "expose_stash => 'foo'", it'll just return

          [1,2]

        instead of the whole object (hashref in perl). This option will be
        useful when you share the method with different views (e.g. TT) and
        don't want to expose non-irrelevant stash variables as in JSON.

    no_x_json_header
          no_x_json_header: 1

        By default this plugin sets X-JSON header if the requested client is
        a Prototype.js with X-JSON support. By setting 1, you can opt-out
        this behavior so that you can do eval() by your own. Defaults to 0.

    json_encoder_args
        An optional hashref that supplies arguments to JSON::MaybeXS used
        when creating a new object.

    use_force_bom
        If versions of this view older than 0.36, there was some code that
        added a UTF-8 BOM marker to the end of the JSON string when the user
        agent was Safari. After looking at a lot of existing code I don't
        think this is needed anymore so we removed it by default. However if
        this turns out to be a problem you can re enable it by setting this
        attribute to true. Possible a breaking change so we offer this
        workaround.

        You may also override the method 'user_agent_bom_test' which
        received the current request user agent string to try and better
        determine if this is needed. Patches for this welcomed.

METHODS
  process
    Standard target of $c->forward used to prepare a response

  render
    The methods accepts either of the following argument signatures in order
    to promote compatibility with the semi standard render method as define
    in numerous Catalyst views on CPAN:

        my $json_string = $c->view('JSON')->render($c, undef, $data);
        my $json_string = $c->view('JSON')->render($c, $data);

    Given '$data' returns the JSON serialized version, or throws and error.

OVERRIDING JSON ENCODER
    By default it uses JSON::MaybeXS::encode_json to serialize perl data
    structure into JSON data format. If you want to avoid this and encode
    with your own encoder (like passing different options to JSON::MaybeXS
    etc.), you can implement the "encode_json" method in your View class.

      package MyApp::View::JSON;
      use base qw( Catalyst::View::JSON );

      use JSON::MaybeXS ();

      sub encode_json {
          my($self, $c, $data) = @_;
          my $encoder = JSON::MaybeXS->new->(ascii => 1, pretty => 1, allow_nonref => 1);
          $encoder->encode($data);
      }

      1;

ENCODINGS
    NOTE Starting in release v5.90080 Catalyst encodes all text like body
    returns as UTF8. It however ignores content types like application/json
    and assumes that a correct JSON serializer is doing what it is supposed
    to do, which is encode UTF8 automatically. In general this is what this
    view does so you shoulding need to mess with the encoding flag here
    unless you have some odd case.

    Also, the comment about regard 'browser gotcha's' was written a number
    of years ago and I can't say one way or another if those gotchas
    continue to be common in the wild.

    NOTE Setting this configuation has no bearing on how the actual
    serialized string is encoded. This ONLY sets the content type header in
    your response. By default we set the 'utf8' flag on JSON::MaybeXS so
    that the string generated and set to your response body is proper UTF8
    octets that can be transmitted over HTTP. If you are planning to do some



( run in 1.878 second using v1.01-cache-2.11-cpan-39bf76dae61 )