#summary Details about the new Lists protocol
#labels Importance-Useful,Phase-Implementation,Contents-Draft

= Introduction =

In this page you can find details about the new lists protocol, made to solve Issue201.

= Protocol format =

The JSON expected should have the following general format (see Details):
{{{
{
  "configuration" : {},
  "operations" : {
    "buttons": [
      {
        "bounds": [],
        "id": "",
        "caption": "",
        "type": "",
        "parameters": {}
      }
    ],
    "row": {
      "type": "",
      "parameters": {}
    }
  },
  "data": {
    "": [
      {
        "columns": {}
        "operations": {
          "buttons": {
            "": {
            }
          }
          "row": {}
        }
      }
    ]
  }
}
}}}

= Details =

This is a step by step description of the protocol.

The very general format is a JSON object with three different objects, indexed by keys, with the following format:

{{{
{
  "configuration" : {},
  "operations": {},
  "data": {}
}
}}}

----
== *configuration* ==
The _configuration_ object is passed *verbatim* to [http://www.trirand.com/blog/ JQGrid], which is the jQuery plugin that is used by Melange to show lists. In this way, it's the Python end that decides every aspect of the appearance of the list. All the informations about the configuration object can be found in [http://www.trirand.com/jqgridwiki/doku.php?id=wiki:jqgriddocs JQGrid Wiki pages], pages concerned are [http://www.trirand.com/jqgridwiki/doku.php?id=wiki:conventions conventions], [http://www.trirand.com/jqgridwiki/doku.php?id=wiki:options options] and [http://www.trirand.com/jqgridwiki/doku.php?id=wiki:colmodel_options colmodel]. However here is a brief example explained:

{{{
"configuration": {
  "colNames": ["Key", "Link ID", "Name", "Program Owner"],
  "colModel": [
    {name: "key", index: "key", resizable: true},
    {name: "link_id", index: "link_id", resizable: true},
    {name: "name", index: "name", resizable: true},
    {name: "program_owner", index: "program_owner", resizable: true}
  ],
  rowNum: 4,
  rowList: [4, 8],
  autowidth: true,
  sortname: "link_id",
  sortorder: "asc",
  height: "auto",
  multiselect: true,
  toolbar: [true, "top"]
}
}}}

  * *colNames*: is an *array of strings* which defines the label of each column as shown to the end user.
  * *colModel*: is an *array of objects*, which defines more details about each column. The number of objects in the array should be the same as the number of strings in the _colNames_ array. The order of the columns detailed in the _colModel_ array should be the same of what's in the _colNames_ array. In this example, each object of the _colModel_ has a *name*, which should be the same name as defined in the "data - columns" object of the protocol. The *index* string (normally same as _name_ string) defines which is the column that is used to order the whole list when clicking on the column. *resizable* is a simple boolean field, which determines if the column of the final list is resizable or not.
  * *rowNum*: is an *integer*, and defines a default of how many rows should be shown for each page of the list
  * *rowList*: is an *array of integers*, which defines a list of choices to the end user of number of elements to be displayed for each page. In this case, the end user can choose to display 4 or 8 elements for each page of the list.
  * *autowidth*: is a *boolean*, which defines if the width of the list should be dinamically changed to fill the whole page.
  * *sortname*: is a *string* that defines which is the default order of the list (should be one of the _name_ string in the _colModel_ array of objects.
  * *sortorder*: should be a *string* chosen from _asc_ and _desc_, to define the default order of the list.
  * *multiselect*: is a *boolean* that should be present if the list should have a column of checkboxes (for example to have multiple deletion of rows at once). See _data/operations/buttons_, _operations/buttons_ (if the list should be a multiselect one) and _operations/row_ (if the list should not be a multiselect one).
  * *toolbar*: is an *array of a boolean and a string*. This should be present as displayed in the example if there are buttons to be displayed on top of the list (for example to show add/edit/delete options, see _data/operations/buttons_ details and _operations/buttons_ details.

----
== *operations* ==
The _operations_ object is used in the protocol to define general behaviour of the list for buttons and rows actions. That is, you can define a number of buttons that will appear on top of the list, e.g. for add/edit/delete links (only consistent if you define {{{toolbar: [true, "top"]}}} in the _configurations_ object), and a default behaviour when a user clicks on a row of the list. Here an example explained:

{{{
"operations": {
  "buttons": [
    {
      "bounds": [0,"all"],
      "id": "add",
      "caption": "Add a user",
      "type": "redirect_simple",
      "parameters": {
        "link": "http://add1",
        "new_window": true
      }
    },
    {
      "bounds": [1,1],
      "id": "edit",
      "caption": "Edit user(s)",
      "type": "redirect_custom",
      "parameters": {
        "new_window": true
      }
    },
    {
      "bounds": [1,"all"],
      "id": "delete",
      "caption": "Delete user(s)",
      "type": "post",
      "parameters": {
        "url": "/user/roles",
        "keys": ["key","link_id"],
        "refresh": "table"
      }
    },
    {
      "bounds": [0,"all"],
      "id": "diff",
      "caption": "Diff between revisions",
      "type": "post",
      "parameters": {
        "url": "/something",
        "keys": ["key","link_id"],
        "redirect": "true"
      }
    }
  ],
  "row" : {
    "type": "redirect_custom",
    "parameters": {
      "new_window": true
    }
  }
}
}}}

=== *buttons* ===
The _buttons_ *array of objects* defines general behaviour for buttons displayed on the top of the list. Each object in the array has the following details:
  * *bounds*: is an *array of integers* or an *array of an integer and the keyword "_all_"*. This array defines a range in which the button is enabled. The _"all"_ keyword is dynamically and automatically substituted with the number of records in the list.
  * *id*: is a *string* that should define a _unique id_ for the button which is referred by _data/operations/buttons_ object. This unique id is limited to the _buttons_ array. IDs with the same name in different lists on the same page don't conflict.
  * *caption*: is a *string* as shown to the end user (this can be customized for each row, see _data/operations/buttons/caption_)
  * *type*: is a *string* which defines the behaviour of the button. At the moment there are three different behaviours you can choose from for buttons: _"redirect_simple"_, _"redirect_custom"_ and _"post"_ (see below).
  * *parameters*: is an *object* that defines (using key/value pairs) parameters for the method _type_ chosen.

Following a list of methods allowed for buttons:
  # *redirect_simple*: this type of behaviour is normally used when the button should be static and should always redirect to the same url (e.g. "Add user"). Parameters accepted are of the following types: {{{"link": "http://whatever"}}} (that is, a *string* with the url the button should redirect to) and {{{"new_window": true}}} (that is, a *boolean* which define whether the redirected page should be shown in a new window or not).
  # *redirect_custom*: this type of behaviour is used when the button should dinamically change the link where the user should be redirected depending on which row is chosen (e.g. "Edit user") (see _data/operations/buttons/link_ and _data/operations/buttons/caption_). Only parameter accepted is {{{"new_window": true}}} (that is, a *boolean* which define whether the redirected page should be shown in a new window or not).
  # *post*: this type of behaviour is used when the button should send something to the backend (e.g. a list of entities to delete). Parameters accepted are of following types: {{{"url": "http://whatever"}}} (that is, a *string* with the url the button should send data to the backend), {{{"keys": ["key","link_id"]}}} (that is, an *array of strings*: each string should be one of the _name_ key in the _colModel_ array, see _configuration/colModel_ and those will define which data should be sent back, using an array of objects, to the backend for each entity selected client side), {{{"refresh": "table"}}} is a *string* which determines whether the table should be refreshed or not: at the moment only "table" option is allowed, support for single "row" refreshing will be made some time in the future. {{{"redirect": "true"}}} means that the server wants the client to be redirected to another page after sending data to the server, and the URL is not known at the moment of the creation of the configuration. The client will send the data requested and expect a JSON like this:

{{{
 "data": {
   "url": "http://new_url_to_redirect_to"
 }
}}}

=== *row* ===
Row actions are allowed only if no {{{multiselect: true}}} is found in the _configuration_ object. Only *redirect_custom* method is allowed, with the same options as for _operations/buttons_. Details to define the url of each row in _data/operations/row_ details.

----
== *data* ==
The _data_ object is used in the protocol to contain the actual data that should be displayed in the list and details about buttons/row click behaviour for each row (when *redirect_custom* is chosen as a method for button/row on _operations/buttons_ and/or _operations/row_). Here an example explained:

{{{
"data": {
  "": [
    {
      "columns": {
        "key": "key_test7",
        "link_id": "test7",
        "name": "Admin Test Example",
        "program_owner": "melange"
      },
      "operations": {
        "buttons": {
          "edit": {
            "caption": "Edit key_test user",
            "link": "http://edit1"
          }
        },
        "row": {
          "link": "http://my_row_edit_link"
        }
      }
    }
  ]
}}}

So, _data_ is an object indexed by key. In the example, you can see what the first iteration (fetching data from backend) should return. The key is actually an empty string. This key should represent the *GAE key of the last entity in the former iteration*. That is, if the last entity fetched is "key_test7" (as in the example), the next iteration should contain "key_test7" as the key of the array of objects in the _data_ object. So, the _data_ returned is indeed an *array of objects*, which has an empty string as index (if it's the first batch) or the GAE key of the last entity fetched in the former batch. Each object (which actually represents a row in the final list) has two objects inside:

=== columns ===
This is the actual data for the row that should be shown to the end user. Each field is indexed by the _name_ chosen in the _colModel_ array (see _configurations/colModel_). It's obviously important that each entity contains exactly the same number and the same names as defined in the _colModel_ array.

=== operations ===
This objects defines details for each row if the chosen _type_ of method for buttons and/or rows (defined in _operations/buttons_ and/or in _operations/row_) is *redirect_custom*. The examples very well explains what is needed.
  * *buttons*: is an *object* which has more than one object inside, indexed by a key. This key is the _id_ defined formerly in _operations/buttons/id_. In this case, the id of the button chosen is _"edit"_. redirect_custom method needs a *caption* (a *string*), which defines what the caption of the button should show when the user clicks on that very row, and a *link* (a *string*) which will be the page where the user should be redirected when that very row is selected and the button is clicked.
  * *row*: is an *object*, which contains only a *link* option, which is a *string* that contains an URL. That string defines where the user should be redirected when clicking on a row.