[#40058] - Changing the order of calling events for fields. FieldsHelper.php
- Closed
- 26 Feb 2024
- Medium
- Build: 4.3-dev
- # 40058
- Diff
- korenevskiy:Change-order-call-plugin-field
User tests: Successful: Unsuccessful:
Due to my confusion with the branches, I have recreated a new PR. #37765
Pull Request for Issue # .
Changed the call of the methods of the event manager.
It was previously done so that for each field 3 dispatcher events were called. For each field, all three events were called at once. After calling 3 events occurs for each new field.
In the new PR, the call of events will be called in a new order.
At the beginning, the first event will be called for all fields. Then, for all fields, a second event is called. And then for all fields calling the third event.
Summary of Changes
Instead of one foreach() in which 3 events are called.
I made 3foreach() in each call one event.
When you open a list of materials on the site. For each material, the same field is displayed. In the case when it is required to have dynamic field data for each material in the list of materials. It may be necessary for the field to have data not only of its material, but also data of all materials. For example, so that each field in the list of materials can have the total value of all data from other fields of the same type
Testing Instructions
class PlgFieldsText extends \Joomla\Component\Fields\Administrator\Plugin\FieldsPlugin{
public $summ = 0;
public function onCustomFieldsBeforePrepareField($context, $item, $field){
if($field->type != 'text')
return;
$this->summ += (int)$field->value;
}
public function onCustomFieldsAfterPrepareField($context, $item, $field, &$value){
if($field->type != 'text')
return;
$value .= ' - Total amount: '. $this->summ;
}
}It should be borne in mind that the value of the text field must be a number.
This example shows the possibilities.
Actual result BEFORE applying this Pull Request
// Result field for article 1: 1 - Total amount: 1
// Result field for article 2: 2 - Total amount: 2
// Result field for article 3: 3 - Total amount: 3Expected result AFTER applying this Pull Request
// Result field for article 1: 1 - Total amount: 6
// Result field for article 2: 2 - Total amount: 6
// Result field for article 3: 3 - Total amount: 6Documentation Changes Required
Not Required
The procedure for calling methods before
Field Article 1 - onCustomFieldsBeforePrepareField()
Field Article 1 - onCustomFieldsAfterPrepareField()
Field Article 2 - onCustomFieldsBeforePrepareField()
Field Article 2 - onCustomFieldsAfterPrepareField()
The procedure for calling methods after
Field Article 1 - onCustomFieldsBeforePrepareField()
Field Article 2 - onCustomFieldsBeforePrepareField()
Field Article 1 - onCustomFieldsAfterPrepareField()
Field Article 2 - onCustomFieldsAfterPrepareField()
The bottom line is that calls should not depend on the order. I completely agree with this. But in cases where it requires the output of fields on the page with a dependency on the order, there is no way to do this. This is required for dynamic data output. In cases where the order of output on the page depends on the content of the data.
This does not violate backward compatibility. Since all static values are rendered in exactly the same way. Also, it does not violate the output of dynamic values. Since if someone outputs dynamic values, then he does not use the existing output order.
This PR is based on making 2 small FORECH out of one FOREACH. By separating plugin calls in separate iterations.
This PR is based on a closed PR #37765
I inform all participants of the last PR
@laoneo @HLeithner
joomla-cms-bot
- | Category | ⇒ | Administration com_fields |
| Status | New | ⇒ | Pending |
This pull request has been automatically rebased to 4.4-dev.
I'v rebased this one to 6.0 as it is a breaking change which can affect extensions when the event call order is changed.
I'm not in favor of this one as we do it always in core like it is now. For example the list views do not prepare all articles first and then do the same for afterTitle, beforeDisplay and afterDisplay. Events should be isolated and your plugin should not depend on a previous call.
@laoneo You've touched on several topics at once. Let's discuss them separately. Because it's not fair to use one topic to prove another:
- Call dependency and isolation. The plugin should not depend on the previous call.
- From the example: in the list of articles, the order does not first make the preliminary preparation of articles, but only then afterTitle, beforeDisplay and afterDisplay.
1.A good private programmer's code for method calls should be isolated. This is a private programmer's problem. Why limit it?
Let's assume that we give an inexperienced developer the opportunity to have a dependency on calling plugin methods. Why do you think he would complicate his life at will using the dependence between methods? The developer will only need this if there is a very strong need. When he has no choice but to do it.
Here you are just trying to impose a way of programming for cases that you know. And I also inform you that there are cases that you haven't thought about yet or they just forgot to think.
The case when it is necessary to output dynamic data. When you need to calculate the amount of money of all products on a page, this is when you need to count the number of fields on the page, this is when you need to number articles in a special way.
I suggest making the possibilities of plugins wider than just displaying static strings.
2.Well, you're right here, the order of pre-preparation of the list of materials is different. Well, maybe it would be great to change their order too. But in any case, if you change the order of calling afterTitle, beforeDisplay and afterDisplay, it will solve the same problem for plugins. But in a general sense, it is useful for all plugins.
It's just that the order of calling these methods has developed historically, when the task was to output just static strings. Won't Joomla expand its capabilities for dynamic fields?
As already mentioned, I'm closing this pr as it would be a too disruptive change for existing extensions. If you still think you need a way of calculating things, then it would probably make more sense to implement new plugin events, instead of changing an existing behavior. Thanks for understanding.
| Status | Pending | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2024-02-26 14:57:18 |
| Closed_By | ⇒ | laoneo | |
| Labels |
Added:
Feature
b/c break
PR-6.0-dev
|
||
But let's put these changes in the major version of the next Joomla, maybe version 7.
What do you recommend to do for dynamic fields? A simple example: the field displays the serial number from the blog list. ?
Events should not depend on other events, so such a change will not go into a further version. You need to find another way the event system is the wrong way.
If the data is static, then it should not. But if the developer's task is exactly such that there is a dependency on calling methods that they should, you cut off the oxygen to him. And he won't be able to solve his problem at all. This is another reason not to use Joomla for large projects.
Events should not depend on other events, so such a change will not go into a further version. You need to find another way the event system is the wrong way.
I can't even create a field so that it displays the order of the blog articles with the total number. Don't you think this is a bad limitation?
1 from 6
2 from 6
3 from 6
4 from 6
5 from 6
6 from 6
...
This is a display of the articles field.
Why doesn't the community want to be able to display this data when it's needed?
@HLeithner Is it possible to transfer this PR to Joomla 5 ?