'view' cell not populated

Without 'view' it is impossible to calculate field on every node view due to caching. To do it and populate 'view' I use:

 case 'view':
      // Added 2007-11-07 by SDSheridan to solve non-compute on View.
      // 'load' above is not called on every view because of caching in cache_content table.
      _computed_field_compute_value($node, $field, $node_field);
      if ($field['display']) {
        $items = array();
        foreach ($node_field as $delta => $item) {
          $view = content_format($field, $item, 'default', $node);
          $items[$delta]['view'] = $view;
          // Populate 'view' unformatted value for theming and other modules
          $node_field[$delta]['view'] = $view;
        }
        return theme('field', $node, $field, $items, $teaser, $page);
      }
      break;

Here it is. I examined how content.module sets 'view', all we need to do is add $node_field[$delta]['view'] = ...
It works, I've got value without label in theme as $node->field_my_computed[0]['view']

There's a simpler way to do this. I don't have access to create a patch right now, but but just change the 'view' function to the following so the value gets stored in $node_field instead of $items:

    case 'view':
      if ($field['display']) {
        foreach ($node_field as $delta => $item) {
          $node_field[$delta]['view'] = content_format($field, $item, 'default', $node);
        }
        return theme('field', $node, $field, $node_field, $teaser, $page);
      }

As I look at this more, I think the better solution would be the patch at http://drupal.org/node/207443, which will accomplish the same thing with less code and more flexibility.

Sorry I missed the beginning of the thread where you did propose this :)

CCK runs widget_invoke('process form values') before every preview, so we can put a calculation in that operation to fix the preview.

To trigger a calc on non-stored fields, I think the best idea would be to clear the node cache to force a new node to be created. Computed field's node_load should come before content module's node_load, so that should force CCK to get a fresh copy.

Then we can leave op='view' handled by CCK.

Would this work? Someone could play around and test that it does, but I think it should.

Subscribing. The posted patch in 11 seems to have fixed my issue @ http://drupal.org/node/246269 :)

#11 loads CCK field values from cache manually:

     // If might be that some computation involves other CCK fields.
     // So we pull them in.
     $cid = 'content:'. $node->nid .':'. $node->vid;
     if ($cached_cck_fields = cache_get($cid, 'cache_content')) {
       foreach (unserialize($cached_cck_fields->data) as $key => $value) {
         $node->$key = $value;
       } 
     }

It is unreliable because at any time cache_content can be cleared by developer or by some modules, which hapens rarely but is pretty legal. In this case calculation fails, so code needs work.

--------------
I'l try to summarize again...

Recalculate on preview feature was introduced by sdsheridan bugfix #134661: Recompute on every display not working?. This issue (titled "'view' cell not populated") is solved without 'view' op removal and do not block #134661: Recompute on every display not working? bugfix. But current feature #207443: CF should allow for other formatters implementation conflicts with current #134661: Recompute on every display not working? bugfix. I think #207443: CF should allow for other formatters is not a duplicate feature, it just touches the same fragment of code.

So we have 1 bug and 3 separate features sharing code:
1. Bug #134661: Recompute on every display not working?, current fix adds new feature to calculate on node preview too.
2. Feature #202384: 'view' cell not populated (current)
3. Feature #207443: CF should allow for other formatters
We might try to fix a bug and implement 3 features at once or fix a bug and decline some features. Final solution sould also calculate fields after CCK fields get loaded and do not break a new great feature committed to CF HEAD -- token support. Looks like a lot of work :)

>The purpose of my code is to make the following feature possible:
>$node = node_load(123);
>print $node->field_something[0]['value'];
>Because I don't see any other way to implement that feature.

Its not the reason to introduce unpredictable behaviour.

> ComputedField's computation doesn't see any other fields

I use patched version which recomputes on view and get your feature like this:

$node = node_load(123);
content_view($node);
print $node->field_something[0]['value'];

>Give me an example, any example, of clearing cache_content.

1. While I export/import/backup sites I never touch caching tables content. I rely on ability to restore a working site at any time with empty cache due to semantics of a cache -- all code using cache must fall back to general load procedure if cache is empty. Caching just speed up things, it do not stores, lets keep this simple principle.

2. I have a production setup -- 2 sites share CCK content types and nodes (2 sites run from one database with some tables shared and some separated with prefixes) but dynamically differently compute fields on view, so the cache tables is not shared between sites. When a node is modified from site 1 all this node cache on site 2 must be revalidated, so I clear modified node cache on site 2 when node is changed on site 1 and vice versa.

So you see, there are some issues in different usecases one can't observe. But we are a community, by "a lot of work" I meen not commiting patches with some workarounds working for me or for you and breaking other's people sites but fixing bugs and add new features without breaking old things people rely on. More testing and feedback needed. Thats a lot of work CF authors may not have time for.

>Perhaps the only course is to fork.
Actually I have a fork of CF for my own needs -- recalculate on preview and on every node view -- 2 lines change. I belive my fork exists not because Agileware do not commit patches but because noone have time to implement this feature and bugfix in a good quality patch.

We have:
1. Bug #134661: Recompute on every display not working?
2. Feature calculate CF on node preview, added by 1.
3. Feature #202384: 'view' cell not populated (current)
4. Feature #207443: CF should allow for other formatters

Lets work on 3 here. #4 code by KarenS looks beautyfull. Can anyone create a patch and help to test?

Ok, thanks for explaination, now I see. Actually I like the idea to have all non db stored CF computed on hook_load, just don't like your implementation. I suggest to call content_load() or duplicate more CCK code to get reliable CCK fields loading.

I use a computed field to provide a link to ubercart to publish a node if it is unpublished. If I activate the field in the node page view, it works perfectly without database involvement. However, I don't display it on the node (for obvious reasons), but on a table view for the user showing his published and unpublished nodes. Therefore I have to use table storage to get this to work.

I used the cf.diff patch (It does not apply clean. I had to do most by hand.) It is almost there. The problem arises if a module sets or unsets $node->status using a query rather than through nodeapi. The computed field is not updated. An example is the admin > content list of nodes. If an administrator changes the 'published' status of a node through this interface, the computed field is not updated, and the old value of the computed field is retained in my view. It is necessary to edit the node, and submit it, to get the field to update in the view, which is an obvious hassle when dealing with many nodes!

Using the stored value in a view suffers from two vulnerabilities. First, this functions which bypass nodeapi, and, second, if the computed field uses values that are updated after the computed field is calculated, hook_load and hook_save have to be run again to insert the correct value in the computed field.

What would be really good, would be a computed field which could be included in a view without being attached to a node. It would allow us to use a php snippet to define a computed column in a view table, using values obtained in the view query. It would also require a <hidden> display property on the field display dropdown, because you might want to make fields available to the php snippet that you did not want to display in the view.

This is a great module if a computed field is needed in a node. The problem arises with views, and every solution I have seen is a bit of a kludge. Might I humbly suggest that the CCK computed field be used in the node, and that you might consider working on a Views computed field as a separate module?

A view is a summary of several logical rows, grouped according to conditions (filters). If I do an invoice, it may be looked at as an embedded view of several line items, each with a unique quantity and unit selling price. As a database designer, it is anathema to store a computed value in a table when the raw information is already there. For reporting, I would retrieve the quantity and price, and calculate the extended total.

Views does not implement this. Whether it is done within the query by defining a calculated field, or done as a php snippet using the raw information retrieved for each row, it is definitely something that would be useful. If the people wish to do a similar calculation in a node, they already have the cck computed field, which works best when the calculated information is not saved to a table.

Elementary separation of structure and function, static information and business process. The whole idea of a computed field is to not have to store it. Less is more.

If we continue to kludge together view compatibility for the cck module, we are going to end up with a bug-ridden maintenance nightmare. Sin is right, it is not elegant. Restrict the cck module to nodes (eliminating the table dependency), and create a similar calculated entity for views... Filtering would not be a problem; thats just a binary decision (display the row or not). Sorting might be a little more difficult, but if the field does not have to appear in nodes, I am sure that sorting could be done. Indeed, if it is a calculated query field, wrap it in an ORDER BY clause, and let the database engine do the sorting.

5.x is unsupported. re-open for 6.x if applicable

I'm using 6.x-1.x-dev, though I also tested with 6.x-1.x-beta5.

My computed fields are not being printed anywhere. I don't see them on nodes, or in views. When I look at the node object I see that the value has been set correctly. When I check out the node object in a preprocess function I see that the "value" is set but the "view" is not. My fields themselves are very simple, just copying another field if it exists. I'm using a custom function rather than defining the php in the interface.

From what I can see in the standard drupal content-field.tpl.php (http://drupalcontrib.org/api/drupal/contributions--cck--theme--content-f...) the var that gets printed is the "view". I also noticed that the "empty" var for that item is being set to true. It seems like I must be missing something significant, as I'm pretty sure I have used computed field before.

Based on this it would seem as though I would have to preprocess each one of these fields and push them into the "view" variable as well as toggle the "empty" variable.

I'm hoping someone can point out some small thing I'm doing wrong so I can get things working!

Thanks,

Kevin

Well this is awkward...

I opened things back up today and the fields were displaying correctly. I'm going to close this up again I guess.