2

I have created a custom content type with three decimal fields. I need to tally these three fields and then wrap the output of each one with a specific data attribute, stating their respective value as a percentage of the total.

Am new to drupal so if someone could point me in the right right direction as to how best achieve this it would be much appreciated.

3

This question is tagged with Views, so I'm just going to go out on a limb and leave this here just in case: Views Calc

This module adds simple calculations to a views table. Requires the Views module.

You can SUM, AVERAGE, COUNT, MIN, MAX, or AVG selected columns. A plug in theme makes the view look more spreadsheet-like (right justifies numeric fields, shades calculated columns and rows, and underlines calculated rows).

2

The standard method to set up variables and pass them to a template file is through the use of a preprocess function. In the case of the node.tpl.php file this would look something like:

function MYTHEME_preprocess_node(&$vars) {
  $field_1_items = field_get_items('node', $node, 'field_something');
  $field_2_items = field_get_items('node', $node, 'field_something_else');

  $computed_value = $field_1_items[0]['value'] + $field_2_items[0]['value'];
  $vars['computed_value'] = $computed_value;
}

Then in your template file you could do something like:

<div class="some-class">
  <?php echo $computed_value; ?>
</div>

That's just an example, your use case will likely differ significantly; but that's the basic method behind it.

Remember that the template files should only ever be used for presentation (adding HTML markup and outputting PHP variables that have been prepared elsewhere), never for logic. The only exception to this is conditional logic (if/switch statements) and other basic logical operations such as &&, ||, etc. As you're performing a calculation on field results you're implementing logic, so using a preprocess function is the correct method in my opinion.

It might seem like a small thing, but separating your presentation and logic will stand you in good stead for future development. If you don't do it you'll end up with a messy code base and future maintenance will be harder than it needs to be :)

  • Creating percentage chart can be considered presentation thing, can't it? I think "calculation = logic" is pretty bold statement. After all, almost every if contains boolean calculations and I've seen a lot of ifs in core's .tpl.php files. Things like this one can be either in data, logic or presentation, depending on intended use, can't they? As long as the author is consistent about it in his project, he should be all right. (I upvoted your answer, by the way) – Mołot May 20 '13 at 8:21
  • Yeah you're right, I was talking about more 'complex' calculations (not boolean/bitwise ops) but I should have clarified. I can't see a situation where calculating the percentage of a group of data would be presentation; displaying that percentage is a presentation issue, but calculating has to be a logical operation in my opinion. I would go one step further and suggest that good software design dictates that the calculation be wrapped in its own class/function to become reusable, which in turn dictates that the data-preparation happens outside of the template file. But that's just me :) – Clive May 20 '13 at 8:40
  • 1
    I was Physics student. This shaped my point of view, making charts and data normalization in a chart-like uses a presentation issue not related in any way to actual logic in your paper or software most of the time. After all, it's nice to see pie diagram of particles after hit, or some %,but what matters before and after is raw numbers, charts and percents are only for quick visual checks and to make people outside your field understand... or believe they understood. Philosophy. – Mołot May 20 '13 at 8:49
  • Very interesting! Can't say I've ever heard a physicist's point of view on this sort of thing before. What you say definitely makes sense from a statistical point of view, but I don't (personally) think it applies to software development. But then I'm just regurgitating the things my lecturers taught me at uni, what I've read in journals/blogs, etc - if they've got it wrong then I've got it wrong too! – Clive May 20 '13 at 8:53
  • What I'm just trying to say is that there is no hard "right" or "wrong" here. With notable exception that inconsistency is always wrong. I agree that logic should be in a pre-process (or even earlier), but line between logic calculations and presentation ones is not set in stone. – Mołot May 20 '13 at 8:57
1

If you consider this to be a presentation issue, best place for this operation is node.tpl.php (or analogous template for content type with fields in question) in your custom theme.

If you consider it a second set of actual data, the way to go is Computed Field module or similar solution.

  • These computed fields are populated with values that you define via PHP code. But the node.tpl will do the job :) – niksmac May 20 '13 at 8:01
  • PHP code in computed fields can access earlier fields. So both options will do the job equally well, applying the same PHP calculations to the same fields. Only difference is in philosophy. Oh, and you can use computed fields in views if you store them in database. – Mołot May 20 '13 at 8:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.