Presets based on content types

I was working today on storing feedapi_item settings on a per node level.

That means basically storing the content types presets per node, once a node is created.

There is lots of overlap between these tasks. If we are happy with presets stored as a serialized array, we could have feedapi handling

* Storing and updating per content type presets
* Storing and updating per node presets

Only by providing feedapi an array in a call back function. E. g.:

feedapi_mymodule_feedapi_settings() {
  $form['content_type'] = array(
       '#type' => 'select',
       '#title' => t('The content-type of the items'),
       '#default_value' => strlen($settings->content_type) > 0 ? $settings->content_type : variable_get('feedapi_item_type', 'story'),
       '#options' => drupal_map_assoc(array_keys(node_get_types())),
       '#description' => t('All of the items related to this feed will be created with this type.'),
      );
  return $form;
}

Storage on a per-content type level and storage on a per node (feed) level would be done by feedapi automatically.

For how much those settings overlap, apply patch and see feedapi_item.module comments

// Extend node edit form.

// Extend the content type form.

Read *per node settings instead of *per node presets in previous post.

I did the implementation of the hook_feedapi_settings_form() as described above. The thing works pretty nifty. An add on module just needs to return a form snippet in this manner...

function parser_simplepie_feedapi_settings_form() {
  $form['test'] = array(
    '#type' => 'textfield',
    '#title' => t('Test'),
    '#description' => t('Test setting'),
    '#default_value' => 3,
  );
  return $form;
}

...and feedapi handles per content type preset storage/manipulation and per feed (=node) settings storage/manipulation. Per content-type presets are stored in the variable table, per node settings are stored in a new settings field in the feedapi table. Enabling/disabling and order of call of add on modules is entirely handled by feedapi module.

How to try out this patch:

* Grab latest DRUPAL-5 cvs version of feedapi
* Install all feedapi modules
* Apply patch
* Create content type and enable feedapi on the content type editing page, chose a parser and a processor, configure presets.
* Create node of this content type.
* Play around with settings.
* You won't be able to actually download feed items with it.

*This patch is still experimental and rather proof of concept.*

Here is what's still missing:

* Testing presets and settings: Creating, updating, deleting.
* Work through the todo's in the code :)
* Load settings on node load so that implementing modules can access them.
* Implement loading feed settings on node load in the feedapi format - feed aggregating should then be possible again.
* Refactor remaining feedapi.module and add on module to adjust to these changes.
* Iron out UI.

patch committed and adapted by aron.