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
Comment #2
dgagne commentedComment #4
dgagne commentedComment #5
dgagne commentedComment #7
dgagne commentedComment #9
dgagne commentedComment #11
dgagne commentedComment #13
dgagne commentedComment #15
dgagne commentedHope this one will not be corrupted ...
Comment #17
dgagne commentedComment #19
dgagne commentedComment #20
dawehnerIs there a reason you cannot use
\Drupal\views\Plugin\views\style\StylePluginBase::getField?Comment #21
dawehnerOh you want to actually manipulate it, that's a bit weird to be honest. Do you mind explaining the usecase?
Comment #22
dgagne commentedWell, 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.
Comment #23
dawehnerAt least having a settter with an explanation of usecases might be useful.
Comment #24
dgagne commentedHere we go, the module implements hook_views_pre_render().
What is done outside of $view:
1) a
$rendered_fieldsvariable is created usingrenderFields(). I cannot usegetField()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 becauseStylePluginBase::$rendered_fieldsis protected. I believe we could implementStylePluginBase::setField()here. I also need to unset non necessary rows inStylePluginBase::$rendered_fields.You may find a copy the hook there: https://www.drupal.org/node/2826682
Comment #25
lendudeWhy not just use a custom StylePlugin? Do we really need to do this in the base class?
Comment #26
dawehnerWell 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.
Comment #27
dgagne commentedI just realized that renderFields() does not return any value. So I'd need to access $rendered_fields to get data as well.
Comment #28
dgagne commented@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.
Comment #29
dgagne commentedFollowing 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.
Comment #30
dgagne commentedChanged title to make it in line with the proposed solution.
Comment #31
dgagne commentedOops, little typo here...
Comment #32
dgagne commentedComment #34
pixelcab commentedI'll work on this as part of Drupal Global Sprint Weekend
Comment #35
dgagne commentedReally ... Big thanks !
Comment #36
pixelcab commentedI 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.
Comment #37
dawehnerI'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.
Comment #38
tstoecklerPer #37
Comment #39
dgagne commentedComment #40
dgagne commented@ 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()orStylePluginBase::setRenderedFields().StylePluginBase::renderFields()does not provide any way to accessStylePluginBase::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_fieldsduring pre-rendering process, and because$view->style_plugin->rendered_fieldsis 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:
Issue summary will be updated accordingly.
Comment #41
dgagne commentedComment #42
dgagne commentedComment #43
dgagne commentedI guess this status is more appropriate because it has already been reviewed/tested.
Comment #44
xjmHi @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.
Comment #45
dgagne commentedComment #46
dawehnerWell, 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.
Comment #47
xjmPostponing on #2824920-25: Make StylePluginBase::renderFields public to give the discussion of the proposed API additions context. Thanks!
Comment #48
xjmComment #57
mlncn commentedRe-roll with tabs to spaces fix. No other changes.
Comment #58
gauravvvv commentedRe-rolled patch #57, fixed custom command failed.
Attached interdiff for same.
Comment #59
ecj commentedWorks like a charm! awaiting to become official patch for views.
Comment #61
joachim commentedI 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.
Comment #65
rudi teschner commentedPatch cannot be applied to 11.2.3, so rerolled
Comment #67
mlncn commentedRealizing we also have a typo in the patch:
should be