/*
 * There are seven types of panels plugins at present: context, relationships,
 * arguments, content_types, styles, layouts, cache; Panels provides an API that
 * allows any module to implement these, but there's a starter set that comes
 * with Panels itself. They're found in the various subdirectories that live under
 * the Panels directory.
 * 
 * All of them (but for our purposes more importantly, content types) start with
 * a 'plugin declaration' function like this one. ALL this function does is return
 * an associative array with a bunch of information for the Panels API to process.
 * The Panels API looks for certain keys in that array - exactly which keys depends
 * on the plugin type - and essentially treats the value in that key as a directive
 * governing how the plugin should behave. Here's what all that concretely means
 * for content types:
 * 
 * Yes, there is some unnecessary duplication with this set of callbacks; they were
 * implemented in this way in order to keep from changing the Panels2 API. They will
 * be made consistent & elegant in Panels3.
 */
function panels_SAMPLE_CT_panels_content_types() {
  $items['SAMPLE_CT'] = array(
    // title (string): SETTING. The title that will be used for this pane on the 'Add Content' modal
    // form, and in the display content editor in general. This is a purely internal setting;
    // normal users will never see it.  
    'title' => t('Sample Content Type'),
    // weight (int): SETTING. Standard drupal weighting concept at work here; all it determines is the
    // position of this content type's icon relative to the other content type icons on the
    // 'Add Content' modal form.
    'weight' => -10,
    // single (bool): SETTING. Indicates that this content type plugin provides only a single content 
    // type. This doesn't have to be included, it's almost more of a note to humans than to
    // the Panels API. Check out panels_admin_content_types_block() to see how one callback
    // can be used to define multiple content types (technically, types AND subtypes).
    // Defaults to FALSE.
    'single' => TRUE,
    // content_types (string): CALLBACK. The Panels API calls this function to get
    // basic information about the content types this plugin provides. See the callback
    // for details.
    'content_types' => 'panels_admin_content_types_SAMPLE_CT',
    // render callback (string): CALLBACK. The Panels API calls this function when it's
    // trying to render the pane for viewing. See the callback for details.
    'render callback' => 'panels_content_SAMPLE_CT',
    // add callback (string): CALLBACK. This function gets called when the user
    // clicks an icon to add a new pane (from the 'Add Content' modal form).
    // See the callback for details; note that it is often possible to use the
    // same, or nearly the same, callback for this as for the 'edit callback.'   
    'add callback' => 'panels_admin_add_SAMPLE_CT',
    // edit callback (string): CALLBACK. This function gets called when the user
    // clicks the 'Configure' button; it partially governs what appears on the
    // configuration modal form that pops up.
    'edit callback' => 'panels_admin_edit_SAMPLE_CT',
    // (add|edit) validate callback (string): CALLBACK. Defines a callback to be
    // used as a FAPI validator, but only for the $form_values set by form items
    // defined in the 'add/edit callback'.
    'add validate callback' => 'panels_admin_add_validate_SAMPLE_CT',
    'edit validate callback' => 'panels_admin_edit_validate_SAMPLE_CT',
    // (add|edit) submit callback (string): CALLBACK. Defines a callback to be
    // used as a FAPI submit handler, but only for the $form_values set by form
    // items defined in the 'add/edit callback'.
    'add submit callback' => 'panels_admin_add_submit_SAMPLE_CT',
    'edit submit callback' => 'panels_admin_edit_submit_SAMPLE_CT',  
    // title callback (string): CALLBACK. This function determines the title that
    // the pane will use, both in the admin interface and for general viewing. Note
    // that this can almost always be overridden 
    'title callback' => 'panels_admin_title_SAMPLE_CT',
    // visibility control (string): CALLBACK. This function gets called at the same
    // time as the add/edit callbacks. Use it to create a form widget that allowing the
    // user to select values that will make sense when passed to your 'visibility check'
    // callback. 
    'visibility control' => 'panels_admin_visibility_control_SAMPLE_CT',
    // visibility submit (string): CALLBACK. The custom submit handler you define
    // for your content type's visibility settings. This function is passed
    // whatever selection the user makes on the form widget defined by the
    // 'visibility control' callback. Implement this if you need to wrangle that
    // data before the Panels API's data storage routines kick in, or if the API's
    // built-in routines are inadequate and you need to build a custom storage
    // mechanism. See panels_content_config_form() and panels_content_config_form_submit()
    // to grok the logic behind if/when/how this callback is triggered. 
    'visibility submit' => 'panels_admin_visibility_submit_SAMPLE_CT',
    // visibility check (string): CALLBACK. The Panels API calls this function during 
    // the pane accessibility checking routine - that's done in panels_pane_access().
    // Define the logic governing your content type's visibility here.
    'visibility check' => 'panels_content_visibility_SAMPLE_CT',
    // visibility serialize (bool): SETTING. Set this to 'true' if the contents of 
    // $pane->visibility need to be serialized before being written to the database. 
    // Set this to TRUE if, for example, your visibility form widget uses checkboxes 
    // (and therefore generates an array), as opposed to if your widget uses radios 
    // (and therefore generates an integer that can be stored directly). See 
    // panels_content_config_form_submit() and panels_save_display() to better
    // understand how this works.
    // Defaults to FALSE.
    'visibility serialize' => TRUE,
    // role-based access (bool): SETTING. Boolean setting to indicate whether you
    // want the your content type to utilize the Panels API's built-in access
    // system, which is based on drupal user roles. Set this to FALSE to disable
    // role-based access. Note that this will automatically be set to FALSE if
    // a 'visibility control' callback is defined.
    // Defaults to TRUE.
    'role-based access' => FALSE,
    // roles and visibility (bool): SETTING. If you want your content type to use
    // both your custom visibility logic and Panels' built-in roles-based access
    // system, then set this to TRUE. Setting 'role-based access' to TRUE is not
    // sufficient; see panels_ajax_ct_preconfigure() to understand how this works.
    // If you use both systems, panels_pane_access() will AND the results together
    // when determining pane visibility.
    'roles and visibility' => TRUE,
    // form control (string): CALLBACK. If the other callbacks governing the add/edit
    // form ('add/edit callback', 'visibility control') aren't enough for your needs,
    // then implement this callback. The callback will be passed a fully-built $form object
    // by reference, and you can alter it as you see fit. Use with caution.
    'form control' => 'panels_admin_form_control_node_content',
  );
  return $items;
}