API page: https://api.drupal.org/api/drupal/core%21modules%21views%21src%21Plugin%...

I would suggest to create 2 new methods that will get data from or set data to $StylePluginBase::rendered_fields.

At first, it was proposed to simply make $StylePluginBase::rendered_fields public instead of being protected. This was rejected as this is not in line with OOP philosophy which requires methods to access properties.

Prior to the proposed solution, creating a derived class of StylePluginBase was considered as well. However, the methods would not spread throughout all style plugins. The latter is a pre-requisite because Views Merge Rows is a display extender intended to work with any style plugin.

Here is a sample of the module code::

$view->style_plugin->renderFields($view->result);
$rendered_fields = $view->style_plugin->getRenderedFields();

Comments

dgagne created an issue. See original summary.

dgagne’s picture

Status: Needs review » Needs work

The last submitted patch, 2: StylePluginBase-public-rendered_fields-2826755-1.patch, failed testing.

dgagne’s picture

StatusFileSize
new234 bytes
dgagne’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 4: StylePluginBase-public-rendered_fields-2826755-2.patch, failed testing.

dgagne’s picture

Status: Needs work » Needs review
StatusFileSize
new175 bytes

Status: Needs review » Needs work

The last submitted patch, 7: StylePluginBase-public-rendered_fields-2826755-3.patch, failed testing.

dgagne’s picture

Status: Needs work » Needs review
StatusFileSize
new177 bytes

Status: Needs review » Needs work

The last submitted patch, 9: StylePluginBase-public-rendered_fields-2826755-4.patch, failed testing.

dgagne’s picture

Status: Needs work » Needs review
StatusFileSize
new177 bytes

Status: Needs review » Needs work

The last submitted patch, 11: StylePluginBase-public-rendered_fields-2826755-5.patch, failed testing.

dgagne’s picture

Status: Needs work » Needs review
StatusFileSize
new178 bytes

Status: Needs review » Needs work

The last submitted patch, 13: StylePluginBase-public-rendered_fields-2826755-6.patch, failed testing.

dgagne’s picture

Status: Needs work » Needs review
StatusFileSize
new165 bytes

Hope this one will not be corrupted ...

Status: Needs review » Needs work

The last submitted patch, 15: StylePluginBase-public-rendered_fields-2826755-7.patch, failed testing.

dgagne’s picture

Status: Needs work » Needs review
StatusFileSize
new210 bytes

Status: Needs review » Needs work

The last submitted patch, 17: StylePluginBase-public-rendered_fields-2826755-8.patch, failed testing.

dgagne’s picture

Status: Needs work » Needs review
StatusFileSize
new484 bytes
dawehner’s picture

Is there a reason you cannot use \Drupal\views\Plugin\views\style\StylePluginBase::getField ?

dawehner’s picture

Oh you want to actually manipulate it, that's a bit weird to be honest. Do you mind explaining the usecase?

dgagne’s picture

Well, I am porting to D8 a module (Views merge rows) because the current D7 maintainer doesn't seem to be active and I need this module. I re-used the code already there and changed many things. I have programming experience but I am new at module / drupal development. My goal was to port the module with minimal changes to make it work.

$rendered_fields was in the module code already and I was not aware of getField(). I try it and will comment back.

dawehner’s picture

At least having a settter with an explanation of usecases might be useful.

dgagne’s picture

Here we go, the module implements hook_views_pre_render().

What is done outside of $view:
1) a $rendered_fields variable is created using renderFields(). I cannot use getField() here because I do not know ID of the fields in advance. If it were the case, I would have looped over row index.

2) this data is then manipulated on a per-field basis (settings vary by field): sum, count, merge data, and so on. This allows much more flexibility than the usual aggregate settings available in views.

3) Manipulated data is then put back in the StylePluginBase::$rendered_fields. Currenty, there is no way to set data back in $view because StylePluginBase::$rendered_fields is protected. I believe we could implement StylePluginBase::setField() here. I also need to unset non necessary rows in StylePluginBase::$rendered_fields.

You may find a copy the hook there: https://www.drupal.org/node/2826682

lendude’s picture

Issue tags: -views

Why not just use a custom StylePlugin? Do we really need to do this in the base class?

dawehner’s picture

Well I guess the idea is to be able to use this across style plugins. Its the classical problem where OOP totally fails down by default: horizontal extensibility.

dgagne’s picture

I just realized that renderFields() does not return any value. So I'd need to access $rendered_fields to get data as well.

dgagne’s picture

@Lenlude:

I tried, but realized that the module wouldn't work with any basic AND custom views style (table, unformatted list, ...). This is clearly not the intent of Views Merge Rows module as one can expect merging to apply no matter what style is used.

dgagne’s picture

Following my work on $DisplayPluginBase::extenders, I wrote functions to get/set the required information from/to $StylePluginBase::rendered_fields so making $stylePluginBase::rendered_fields public is no longer necessary. I had problems with git so I was unable to produce an interdiff file.

dgagne’s picture

Title: Make $StylePluginBase::rendered_fields public » Create a public read/write interface for $DisplayPluginBase::rendered_fields

Changed title to make it in line with the proposed solution.

dgagne’s picture

Title: Create a public read/write interface for $DisplayPluginBase::rendered_fields » Create a public read/write interface for $StylePluginBase::rendered_fields

Oops, little typo here...

dgagne’s picture

Issue tags: +Novice

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

pixelcab’s picture

I'll work on this as part of Drupal Global Sprint Weekend

dgagne’s picture

Really ... Big thanks !

pixelcab’s picture

Status: Needs review » Reviewed & tested by the community

I was able to successfully apply the patch to my local Drupal 8.4.0-dev instance. The getRenderedFields & setRenderedField public methods were added to the StylePluginBase. I was able to verify the patch is working by testing the update on the development version (8.x-1.0-dev) of the views_merge_rows.module which was already using the the two added methods, getRenderedFields & setRenderedField. After applying the this patch the module was able to use and have the correct access to use the new methods.

dawehner’s picture

I'm highly dubious whether this issue is needed on top of #2824920: Make StylePluginBase::renderFields public
I'd suggest to make a clear issue summary, explain why the solutions proposed here are the only available ones and explain why there is no better solution from an architecture point of view.

tstoeckler’s picture

Status: Reviewed & tested by the community » Needs work

Per #37

dgagne’s picture

dgagne’s picture

@ dawehner:

This issue is clearly needed on top of #2824920: Make StylePluginBase::renderFields public. Fields have to be rendered prior to being able to use StylePluginBase::getRenderedFields() or StylePluginBase::setRenderedFields(). StylePluginBase::renderFields() does not provide any way to access StylePluginBase::rendered_fields.

As mentionned in issue #2824920: Make StylePluginBase::renderFields public, the module Views Merge Rows is a display extender plugin that modify Views output by implementing hook_views_pre_render(). Because the module needs to access $view->style_plugin->rendered_fields during pre-rendering process, and because $view->style_plugin->rendered_fields is not rendered prior to the execution ofhook_views_pre_render, invoking $view->style_plugin->renderFields($view->result) is made necessary. Then access methods can be used.

Here is a sample of the module code:

$view->style_plugin->renderFields($view->result);
$rendered_fields = $view->style_plugin->getRenderedFields();

Issue summary will be updated accordingly.

dgagne’s picture

Issue summary: View changes
dgagne’s picture

Status: Needs work » Needs review
dgagne’s picture

Status: Needs review » Reviewed & tested by the community

I guess this status is more appropriate because it has already been reviewed/tested.

xjm’s picture

Status: Reviewed & tested by the community » Needs review
Issue tags: +Needs subsystem maintainer review

Hi @dgagne, thanks for your work on this!

In general, you should not set the "Reviewed & tested by the community" status on patches you create yourself, even if someone did previously before other feedback. In our core process, a peer reviewer should generally do that.

I am setting this NR and "Needs subsystem maintainer feedback" to see if #40 indeed addresses @dawehner's question as a Views maintainer.

dgagne’s picture

Assigned: Unassigned » dgagne
dawehner’s picture

This issue is clearly needed on top of #2824920: Make StylePluginBase::renderFields public

Well, this is what you say :) Do you mind writing a clear issue summary to explain the problem space, explain why your multiple issues are the only way to solve that problem ... Just changing that is hard.

xjm’s picture

Status: Needs review » Postponed

Postponing on #2824920-25: Make StylePluginBase::renderFields public to give the discussion of the proposed API additions context. Thanks!

xjm’s picture

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

mlncn’s picture

Assigned: dgagne » Unassigned
Status: Postponed » Needs review
StatusFileSize
new1.5 KB

Re-roll with tabs to spaces fix. No other changes.

gauravvvv’s picture

StatusFileSize
new1.49 KB
new806 bytes

Re-rolled patch #57, fixed custom command failed.

Attached interdiff for same.

ecj’s picture

Works like a charm! awaiting to become official patch for views.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

joachim’s picture

Status: Needs review » Needs work
+++ b/core/modules/views/src/Plugin/views/style/StylePluginBase.php
@@ -801,6 +803,30 @@ public function getField($index, $field) {
+   *   The output of all rendered fields, or NULL if it was empty.

I think it would be better DX to return an empty array rather than a NULL, because then you can always iterate over it without having to check it first. Returning NULL means a caller needs to do isset() first.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

rudi teschner’s picture

Patch cannot be applied to 11.2.3, so rerolled

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.

mlncn’s picture

Realizing we also have a typo in the patch:

   * @see \Drupal\views\Plugin\views\style\StylePluginBase::setRenderedFields()

should be

   * @see \Drupal\views\Plugin\views\style\StylePluginBase::setRenderedField()