I'm able to use $entity successfully in display code entered into the field configuration form directly. However, attempting to use $entity in a custom display function results in an error indicating that $entity is undefined. Any chance it can be made available to custom display functions?

Additionally, while working on this, I found that:

computed_field_field_job_posting_number_display($field, $entity_field_item, $entity_lang, $langcode)

...resulted in errors indicating that $entity_lang and $langcode were undefined. I had to remove them from the function's arguments list.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

rjacobs’s picture

Version: 7.x-1.0-beta1 » 7.x-1.x-dev

Yes, this would be a nice tweak. Being able to use the "display code" as a way to dynamically aggregate data from other fields and/or entity info into a custom field is a nice feature of this module. However, as wrd pointed out, this is currently is not possible without storing code in the DB (which is not ideal).

It looks like the custom display function is called inside computed_field_field_formatter_view() with the following:

if ($display_in_code) {
  $display_output = $display_func($field, $entity_field_item, $entity_lang, $langcode);
}

Given that $entity is also available in the computed_field_field_formatter_view() scope, it would seem this could be accomplished via a simple adjustment of the above snippet to something like:

if ($display_in_code) {
  $display_output = $display_func($field, $entity_field_item, $entity_lang, $langcode, $entity);
}

$entity would have to be added to the end for backwards-compatibility I suppose. Some string tweaks would also be needed on the settings form details.

It would be interesting to hear from a maintainer as to whether-or-not there is a good reason not to do this, especially as $entity is already available to eval'd versions of the display code.

rjacobs’s picture

Status: Active » Needs review
FileSize
2.41 KB

How about the attached patch? This was made with git format-patch and is against dev. It's based on the points from comment #1

wrd, perhaps you can test this out?

rjacobs’s picture

Title: Can $entity be made available to custom display functions? » $entity data is not available to custom display functions, which greatly limits what custom logic can be used there
Category: feature » bug

I'm going to categorize this as a bug report for now. My justification for doing this is the fact that the module description states the following:

These computed fields are populated with values that you define via PHP code. You may draw on anything available to Drupal, including other fields, the current user, database tables, you name it.

The issue here is that in the case of a custom field that a.) does not store it's values in the database, and b.) uses a custom display function (as opposed to evaluated code), I don't think it's actually possible to "draw on anything available to Drupal". Specifically it does not seem to be possible to tap into the values of "other fields", as the values passed to the custom display function do not contain any reference to the current entity id, let alone the entity itself. This means that we can't even do an entity_load() to get the entity data.

If I'm being too liberal on my use of "bug report" here, please change back. However, unless I'm missing something, this is a somewhat limiting situation and the fix should be pretty straightforward. I know it's always possible to define custom fields manually with the fields API to get around this, but for prototyping purposes it's sooo much more efficient to use this handy module.

rjacobs’s picture

Just wanted to bump this.

Is there anyone else out there interested in this? I can't review my own patch and my guess is that the maintainers aren't interested in things not marked RTBC.

Sometimes one just needs a tool to build dynamic chunks of content that are computed from existing entity data (no need to add the data to the database), and having that chunk act like a field is very powerful for prototyping purposes. It would be a shame to have to write my own tool to do this given that this kind of feature seems squarely within the intended domain of computed_fields.

AaronBauman’s picture

Status: Needs review » Reviewed & tested by the community

I'd argue it's all but imperative that display_func have access to the same arguments as the hook_field_formatter_view function.
(In fact, I'd argue that the display_func should have exactly the same function signature as hook_field_formatter_view, but at this point that would break all existing implementations and therefore not be practical.)

Definitely a bug, since the display_func has necessarily less functionality than it would had it been defined only through field settings.
RTBC++

rjacobs’s picture

Thanks for reviewing Aaron!

colan’s picture

Issue summary: View changes
Status: Reviewed & tested by the community » Fixed

Committed in d41e3f4.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.