TwitterField

The submitted project was created out of a an issue in the Twitter module queue, #690984: Twitter CCK Field or add to content type.

A couple users provided the example of a content type for artists, and the desired functionality is to link nodes of this content type to individual twitter accounts. A single user may create multiple artist nodes, and a single artist may be editable by multiple users.

Twitter Module (http://drupal.org/project/twitter)
Twitter module only supports integration between site users and their twitter accounts; no integration is available for content types and CCK fields as is provided by the submitted module.

The submitted module doesn't authenticate and link twitter account information as the Twitter module does. The submitted module only validates the format of inputted content according to configured criteria.

Noted workarounds for Twitter module to implement the submitted module's functionality include the use of Computed Fields, or the creation of dummy user accounts in order to utilize Twitter module's included user account association. Both methods are significantly more complex than utilizing my submitted module, and are unlikely to be performed by a Drupal user or site builder without significant Drupal experience.

Twitter Pull (http://drupal.org/project/twitter_pull)
This module only supports the display of Twitter information.

Integration is planned, with the creation of an additional formatter that utilizes Twitter Pull for output as an alternative to the Twitter Widget formatter that is currently implemented.

Twitter Field (Project application: #1075566: Tweet Field)
This module allows signifying a text field within a content type for storing a tweet that will be sent to a designated twitter account upon saving the node. A single site-wide twitter account can be specified, which all tweets will be sent to.

This module does not support storing or displaying twitter account names, hashtags, etc, as provided in the submitted module. Tweet Field was recommended as an alternate name for this module in the application review to better describe its functionality.

----

I was unable to find other modules that provide similar functionality to the submitted module.

I've added the module to the CCK package, and added the dependency on content.module. (commit diff)

I do agree that there is a bit too much logic within the .tpl file; I've now moved much of it into theme_twitterfield_formatter_twitter_widget() and added more documentation on the variables available within twitter-widget.tpl.php. (commit diff)

The Twitter Widget could be output directly from the theme function, but it is likely that module users will wish to modify the settings, and the .tpl file makes this much simpler and more accessible than a theme function.

I had attempted to use drupal_add_js() to include the external javascript file, trying to avoid adding it to the page multiple times if multiple fields are displayed on the page. I found, however, that D6 wasn't designed to support including external files (#91250: JavaScript Patch #4: External Scripts has added support to D7).
There shouldn't be any ill-effects from including the external javascript multiple times: multiple requests will receive a '304: Not Modified' response, and the code is designed to only execute once.

The Twitter Widget code is provided by Twitter to be included inline in a page; not inline as drupal_add_js() provides where the code is added at the foot of the page, but placed within the DOM where the widget is to be output on the page.

The only 'clutter' in the template file, which is not "print, if, and maybe foreach" is this, which simply allows the final line of javascript to be more compact:

if ($type == 'profile') {
  $widget_chain = ".setUser('" . $value . "')";
}
elseif ($type == 'list') {
  $widget_chain = ".setList('" . $value[0] . "', '" . $value[1] . "')";
}

The rest of the template is really no different in intent or implementation than any HTML .tpl file, other than it is outputting a script tag.

----

The only implementation I can think of for what you seem to be suggesting, is only outputting a div element (e.g. <div id='twitter-widget--field_twitter_0'></div>, then adding settings with drupal_add_js() for each div added to the page drupal_add_js(array('twitterfield' => array('field_twitter_0' => array('type' => 'profile', 'value' => 'drupal', 'subject' => '@drupal'))), 'setting').
A local, static JS file would run at the end of the page load to add the Twitter Widgets according to the settings for their respective DIV elements. To override the display settings for the widget, a user would have to modify this static file.

I believe there are several problems with that method:
First, I think it adds unneeded complexity and makes the possibility of overriding the widget settings much less accessible.
From a quick search, it also appears that it would only be possible to override the static JS file in D7 (hook_js_alter()), which rules this out as an option for this D6 module.
Lastly, the Twitter Widgets page provides no information on implementing the widgets in a manner other than inserting the JS snippets directly in the page where they are to be rendered.

Should someone understand the Twitter Widget functionality to an extent where they could make this possible, I would consider a patch to implement this method provided it can be shown not to add unnecessary complexity to the task of overriding the widget settings via a theme.

A small addition, but I think it is worth noting that I have now added integration with twitter_pull module, to utilize it as another display formatter option.

I've opened an issue in the project's queue on removing the tpl file and creating the widgets after page load: #1216920: Don't use tpl file for Twitter Widget.
I think it will take some research and experimentation before it's possible, as I couldn't find any official documentation with a quick search but did see one page with mention of an id option for the settings object as @michaek mentioned (though with an older version of the widget, and I don't know how it interacts with the .render() and .start() calls).

----

As I mentioned in #690984: Twitter CCK Field or add to content type, I would appreciate feedback from others on what they would prefer in regards to packaging TwitterField with Twitter module or keeping it separate, and what factors are more important to them (e.g. consolidation of related modules / granularity of project downloads, linking / separation of releases).

I've fixed the mentioned issues in the 7.x branch.

As a note, the 7.x branch is primarily another user's work and I only updated it to the same namespace as my module, in order to quickly make it available for someone who requested it.
The 6.x branch is more feature-complete, and is solely my own work (though one feature was ported from the other user's work in 7.x).

Thank you for the reviews, @klausi

Coder doesn't indicate any relevant errors, and I'm unable to see any issues with the indentation in twitterfield_widget_settings() myself.

The error conditions should be mutually exclusive, and so only one will even match; I've changed the conditionals to elseifs to reflect this (and improve performance ever so slightly).

Comment is fixed, and additional function docblocks are added.

Thanks to all for the reviews and suggestions!