I've run into some trouble with the documented limitations of this module. So instead of using SQL to make calculations I tried grabbing the $field_output and doing calculations on that in the template_preprocess function.

The benefits to this approach are that it will make it possible to do things like use relationships, do any kind of math you want on the field itself, use any kind of grouping you want, and maybe eventually to override the Views grouping to offer multiple levels of grouping and tabulate across rows as well as columns.

I've created a version of this module and am placing it here for right now: https://github.com/zivtech/views_field_calc

I'm interested to hear what people think of this approach. Could this be another display option for this module or should it be it's own module on D.O. or neither?

Comments

miro_dietiker’s picture

Do you have any solution to the grand total for multi page situations?

MerlinOfChaos was once talking about native ctools/views support for aggregation functions which possibly make this module deprecated. We still ported it as a start.

In Drupal 7 things are cleaner: It is important that real fields are stored as real fields and not e.g. unserialized on presentation - this is a breach in concept of the persistence layer and we cannot reliably detect it.

While enumerating on a single page might help to make page aggregations and it even reduces query amounts and makes 100% reliable results (while a separate aggregation query might lead to a wrong result if transactions happen at exactly between output of the lines and the aggregation query) ... I see really no way to make this approach scaleable in a multipage output: every line of (e.g. hundreds of pages) need to be calculated and summed. It's the job of the persistency layer to support aggregation with high efficiency.

If field definitions would contain information about persistency -- that views_calc could know what can be done in sql and what need to be done on the output level -- we could support a hybrid mode. In that case i'd drop the grand total case for multipage things in output aggregation mode.

The important question is: Can we add this hybrid mode with LIMITED additional complexity?
Can we autodetect?
Do we need a setting (e.g. per field?)

acouch’s picture

| Do you have any solution to the grand total for multi page situations?

The solution I'm imagining would be to override the grouping in the table style plugin and replacing it with one controlled by this module so that you can get all of the results at once and group however you please. Then you could have totals for the whole set as well as each grouping.

| I see really no way to make this approach scaleable in a multipage output: every
| line of (e.g. hundreds of pages) need to be calculated and summed.

This approach, as of right now, grabs all of the results from each row from each field that has a calculation, and performs one calculation per field. So I don't think it would matter that much if you had 10 or 100 or 1000 rows.

ahtih’s picture

As I understand, your module is for Views 3 only? If so it would be good to mention that in documentation and hook_requirements().

miro_dietiker’s picture

It is clearly noted on the frontpage what dependencies we have.

Please provide a hook_requirements implementation and we can integrate it.
For next subject of development (Drupal 7) this is no issue as we can declare it in the info file.

acouch’s picture

Issue summary: View changes
Status: Active » Closed (works as designed)