Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Added in some options that i used to use computed fields to do
http://drupal.org/node/249907
function textcommaformatter_field_formatter_info() {
return array(
'text_comma' => array('label' => t('Commas'), 'multiple values' => CONTENT_HANDLE_MODULE, 'field types' => array('text')),
'text_comma_and' => array('label' => t('Commas-And'), 'multiple values' => CONTENT_HANDLE_MODULE, 'field types' => array('text')),
'text_comma_and_period' => array('label' => t('Commas-And-Period'), 'multiple values' => CONTENT_HANDLE_MODULE, 'field types' => array('text')),
'text_unordered_list' => array('label' => t('Unordered List'), 'multiple values' => CONTENT_HANDLE_MODULE, 'field types' => array('text')),
'text_ordered_list' => array('label' => t('Ordered List'), 'multiple values' => CONTENT_HANDLE_MODULE, 'field types' => array('text')),
);
}
/**
* Implementation of hook_theme().
*/
function textcommaformatter_theme() {
return array(
'textcommaformatter_formatter_text_comma' => array('arguments' => array('element' => NULL), 'function' => 'theme_textcommaformatter_formatter_text_comma'),
'textcommaformatter_formatter_text_comma_and' => array('arguments' => array('element' => NULL), 'function' => 'theme_textcommaformatter_formatter_text_comma'),
'textcommaformatter_formatter_text_comma_and_period' => array('arguments' => array('element' => NULL), 'function' => 'theme_textcommaformatter_formatter_text_comma'),
'textcommaformatter_formatter_text_unordered_list' => array('arguments' => array('element' => NULL), 'function' => 'theme_textcommaformatter_formatter_text_comma'),
'textcommaformatter_formatter_text_ordered_list' => array('arguments' => array('element' => NULL), 'function' => 'theme_textcommaformatter_formatter_text_comma'),
);
}
/**
* Theme a textfield as a comma-separated list.
*
* @ingroup themeable
*/
function theme_textcommaformatter_formatter_text_comma($element) {
$values = array();
$item = $element;
foreach (element_children($element) as $key) {
unset($item[$key]);
}
foreach (element_children($element) as $key) {
$item['#item'] = $element[$key]['#item'];
$values[] = ($allowed =_text_allowed_values($item)) ? $allowed : $item['#item']['safe'];
}
switch ($element['#formatter']) {
case 'text_comma':
$output = implode(', ', $values);
break;
case 'text_comma_and':
$output = ImplodeToEnglish($values, ', ', '');
break;
case 'text_comma_and_period':
$output = ImplodeToEnglish($values, ', ', '.');
break;
case 'text_unordered_list':
$output = ImplodeToList($values, 'ul');
break;
case 'text_ordered_list':
$output = ImplodeToList($values, 'ol');
break;
}
return $output;
}
//taken from http://us.php.net/manual/en/function.implode.php#86845
function ImplodeToEnglish ($array, $seperator, $suffix) {
// sanity check
if (!$array || !count ($array)) {
return '';
}
// get last element
$last = array_pop ($array);
// if it was the only element - return it
if (!count ($array)) {
return $last;
}
//return x, x, x and x.
return implode ($seperator, $array) . t(' and ') . $last . $suffix;
}
function ImplodeToList ($array, $type) {
// sanity check
if (!$array || !count ($array)) {
return '';
}
return '<'.$type.'>'."\n".'<li>' . implode ('</li>'."\n".'<li>', $array) . '</li>'."\n".'</'.$type.'>';
}
Will add in the first/last for the number field soon, as well as a fill in the blank if null. example: price is blank then display "call for price".
Comment | File | Size | Author |
---|---|---|---|
#10 | textformatter.diff | 3.9 KB | mikeytown2 |
#8 | cck_formatters.tar_.gz | 3.4 KB | mikeytown2 |
#4 | textcommaformatter.tar_.gz | 1.43 KB | mikeytown2 |
#3 | textcommaformatter.module.diff | 4.38 KB | mikeytown2 |
#2 | textcommaformatter.module.diff | 3.53 KB | mikeytown2 |
Comments
Comment #1
Crell CreditAttribution: Crell commentedThis is not a patch. http://drupal.org/patch/create
Comment #2
mikeytown2 CreditAttribution: mikeytown2 commentedhere is is in diff. Thanks for pointing me in the right direction.
Comment #3
mikeytown2 CreditAttribution: mikeytown2 commentedhere's the correct diff. I also added in even odd classes for the list output.
Comment #4
mikeytown2 CreditAttribution: mikeytown2 commentedhere it is as a tar
Comment #5
drewish CreditAttribution: drewish commentedyou need to be using spaces for indenting rather than tabs. also split up long array()s into multiple lines the way the module is already doing.
here's an anded list implementation i did a while back that seems a little cleaner:
Comment #6
mikeytown2 CreditAttribution: mikeytown2 commentedIs there a coding standards page where I can find out how I'm supposed to format the code? In terms of arrays into multiple lines, I was following how the CCK Numbers module codes it. I've been gone, so now that i"m back this is my first project; to code for this module. I'm planing on making a support module to hold all the general functions, there is too much repeating code.
Comment #7
mikeytown2 CreditAttribution: mikeytown2 commentedok, I will follow the code standards
http://drupal.org/coding-standards
Will release a tarball in a little while, with the "cckformatterfunctions" module
*Slightly Off Topic*
Is there a pre-configured text editor that follows the rules for xp? Something that is similar to how Autoit Packages it?
http://www.autoitscript.com/autoit3/scite/downloads.shtml
Comment #8
mikeytown2 CreditAttribution: mikeytown2 commentedHere it is... The only thing that is not generalized is the price in the numbers formatter display; it's too specific to be useful it's current form to the general community. If this looks like it passes the drupal coding standards then I will start to redo some of this so that it's more "elegant".
Followup to my off topic... If you have the autoit version of scite, add this to SciTEUser.properties (in C:\Documents and Settings\user name)
It gives you a local SVN and correct tabs/return for your module files.
Comment #9
Crell CreditAttribution: Crell commentedAre you submitting new modules, or patches for existing modules? Please only include patches if modifying an existing module.
Comment #10
mikeytown2 CreditAttribution: mikeytown2 commentedkinda both, you could say I'm writing a patch for your text one and I have 3 new modules on top of it. Plus the text one now has a new dependency and is renamed. Anyway here is the diff for your text one.
Comment #11
Crell CreditAttribution: Crell commentedHm. Renaming it could be quite problematic given the way CVS works. I'll have to check with the CVS maintainers but at that point it's probably better to add a new module to the package named textformatter, then remove the old one. :-(
That said, we should *not* use the same theme function for all of the formatters. A switch statement is 99% of the time a clear indication that you're doing something wrong. Let's have a separate theme function for each, which can then also be overridden separately for each. Thanks.
(I wonder if we should just split off textformatter to its own module then? Something to ask Karen about, probably.)
Comment #12
mikeytown2 CreditAttribution: mikeytown2 commentedI would like to keep them all in one big package, that way I can use a standard library of functions for all the formatters. My next step is to replicate how lightbox2 adds in multiple items for images, and do it for numbers; and kill my price option. Also would like to code an imagefield formatter as well. I'm thinking about the best way to kill the switch statement right now. I'll also change the "comma and" code to your more elegant solution.
Thanks for your help!
Comment #13
Crell CreditAttribution: Crell commentedIf you don't specify a function in the theme hook, then you would automatically get theme functions of theme_textformatter_formatter_text_comma(), theme_textformatter_formatter_text_comma_and(), theme_textformatter_formatter_text_comma_and_period(), etc. That's a much better way to go, as you then have nice small polymorphic functions to leverage rather than one big beheamoth of a switch. That's the correct way to handle it, IMO.
I'm not suggesting we split each text formatter into its own module, as that is I agree excessive. I am wondering if it makes sense to create a new module project named "textformatters" that contains just a whole bunch of formatters for text fields, starting with the one there now and the ones in this thread.
Comment #14
eabrand CreditAttribution: eabrand commentedThis has become its own module. check here: http://drupal.org/project/textformatter
Comment #15
Crell CreditAttribution: Crell commented