NAME
    Catalyst::View::JSON - JSON view for your data

SYNOPSIS
      # lib/MyApp/View/JSON.pm
      package MyApp::View::JSON;
      use base qw( Catalyst::View::JSON );
      1;

      # configure in lib/MyApp.pm
      MyApp->config({
          ...
          'View::JSON' => {
              allow_callback  => 1,    # defaults to 0
              callback_param  => 'cb', # defaults to 'callback'
              expose_stash    => [ qw(foo bar) ], # defaults to everything
          },
      });

      sub hello : Local {
          my($self, $c) = @_;
          $c->stash->{message} = 'Hello World!';
          $c->forward('View::JSON');
      }

DESCRIPTION
    Catalyst::View::JSON is a Catalyst View handler that returns stash data
    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
    alternative encoding you should turn off this default via the
    "json_encoder_args":

        MyApp::View::JSON->config(
          json_encoder_args => +{utf8=>0} );

    NOTE In 2015 the use of UTF8 as encoding is widely standard so it is
    very likely you should need to do nothing to get the correct encoding.
    The following documentation will remain for historical value and
    backcompat needs.

    Due to the browser gotchas like those of Safari and Opera, sometimes you
    have to specify a valid charset value in the response's Content-Type
    header, e.g. "text/javascript; charset=utf-8".

    Catalyst::View::JSON comes with the configuration variable "encoding"
    which defaults to utf-8. You can change it via "YourApp->config" or even
    runtime, using "component".

      $c->component('View::JSON')->encoding('euc-jp');

    This assumes you set your stash data in raw euc-jp bytes, or Unicode
    flagged variable. In case of Unicode flagged variable,
    Catalyst::View::JSON automatically encodes the data into your "encoding"
    value (euc-jp in this case) before emitting the data to the browser.

    Another option would be to use *JavaScript-UCS* as an encoding (and pass
    Unicode flagged string to the stash). That way all non-ASCII characters
    in the output JSON will be automatically encoded to JavaScript Unicode
    encoding like *\uXXXX*. You have to install Encode::JavaScript::UCS to
    use the encoding.

CALLBACKS
    By default it returns raw JSON data so your JavaScript app can deal with
    using XMLHttpRequest calls. Adding callbacks (JSONP) to the API gives
    more flexibility to the end users of the API: overcome the cross-domain
    restrictions of XMLHttpRequest. It can be done by appending *script*
    node with dynamic DOM manipulation, and associate callback handler to
    the returned data.

    For example, suppose you have the following code.

      sub end : Private {
          my($self, $c) = @_;
          if ($c->req->param('output') eq 'json') {
              $c->forward('View::JSON');
          } else {
              ...
          }
      }

    "/foo/bar?output=json" will just return the data set in "$c->stash" as
    JSON format, like:

      { result: "foo", message: "Hello" }

    but "/foo/bar?output=json&callback=handle_result" will give you:

      handle_result({ result: "foo", message: "Hello" });

    and you can write a custom "handle_result" function to handle the
    returned data asynchronously.

    The valid characters you can use in the callback function are

      [a-zA-Z0-9\.\_\[\]]

    but you can customize the behaviour by overriding the
    "validate_callback_param" method in your View::JSON class.

    See <http://developer.yahoo.net/common/json.html> and
    <http://ajaxian.com/archives/jsonp-json-with-padding> for more about
    JSONP.

    NOTE For another way to enable JSONP in your application take a look at
    Plack::Middleware::JSONP

INTEROPERABILITY
    JSON use is still developing and has not been standardized. This section
    provides some notes on various libraries.

    Dojo Toolkit: Setting dojo.io.bind's mimetype to 'text/json' in the
    JavaScript request will instruct dojo.io.bind to expect JSON data in the
    response body and auto-eval it. Dojo ignores the server response
    Content-Type. This works transparently with Catalyst::View::JSON.

    Prototype.js: prototype.js will auto-eval JSON data that is returned in
    the custom X-JSON header. The reason given for this is to allow a
    separate HTML fragment in the response body, however this of limited use
    because IE 6 has a max header length that will cause the JSON evaluation
    to silently fail when reached. The recommend approach is to use
    Catalyst::View::JSON which will JSON format all the response data and
    return it in the response body.

    In at least prototype 1.5.0 rc0 and above, prototype.js will send the
    X-Prototype-Version header. If this is encountered, a JavaScript eval
    will be returned in the X-JSON response header to automatically eval the
    response body, unless you set *no_x_json_header* to 1. If your version
    of prototype does not send this header, you can manually eval the
    response body using the following JavaScript:

      evalJSON: function(request) {
        try {
          return eval('(' + request.responseText + ')');
        } catch (e) {}
      }
      // elsewhere
      var json = this.evalJSON(request);

    NOTE The above comments were written a number of years ago and I would
    take then with a grain of salt so to speak. For now I will leave them in
    place but not sure they are meaningful in 2015.

SECURITY CONSIDERATION
    Catalyst::View::JSON makes the data available as a (sort of) JavaScript
    to the client, so you might want to be careful about the security of
    your data.

  Use callbacks only for public data
    When you enable callbacks (JSONP) by setting "allow_callback", all your
    JSON data will be available cross-site. This means embedding private
    data of logged-in user to JSON is considered bad.

      # MyApp.yaml
      View::JSON:
        allow_callback: 1

      sub foo : Local {
          my($self, $c) = @_;
          $c->stash->{address} = $c->user->street_address; # BAD
          $c->forward('View::JSON');
      }

    If you want to enable callbacks in a controller (for public API) and
    disable in another, you need to create two different View classes, like
    MyApp::View::JSON and MyApp::View::JSONP, because "allow_callback" is a
    static configuration of the View::JSON class.

    See <http://ajaxian.com/archives/gmail-csrf-security-flaw> for more.

  Avoid valid cross-site JSON requests
    Even if you disable the callbacks, the nature of JavaScript still has a
    possibility to access private JSON data cross-site, by overriding Array
    constructor "[]".

      # MyApp.yaml
      View::JSON:
        expose_stash: json

      sub foo : Local {
          my($self, $c) = @_;
          $c->stash->{json} = [ $c->user->street_address ]; # BAD
          $c->forward('View::JSON');
      }

    When you return logged-in user's private data to the response JSON, you
    might want to disable GET requests (because *script* tag invokes GET
    requests), or include a random digest string and validate it.

    See
    <http://jeremiahgrossman.blogspot.com/2006/01/advanced-web-attack-techni
    ques-using.html> for more.

AUTHOR
    Tatsuhiko Miyagawa <miyagawa@bulknews.net>

LICENSE
    This library is free software; you can redistribute it and/or modify it
    under the same terms as Perl itself.

CONTRIBUTORS
    Following people has been contributing patches, bug reports and
    suggestions for the improvement of Catalyst::View::JSON.

      John Wang
      kazeburo
      Daisuke Murase
      Jun Kuriyama
      Tomas Doran

SEE ALSO
    Catalyst, JSON::MaybeXS, Encode::JavaScript::UCS

    <http://www.prototypejs.org/learn/json>
    <http://docs.jquery.com/Ajax/jQuery.getJSON>
    <http://manual.dojotoolkit.org/json.html>
    <http://developer.yahoo.com/yui/json/>