[#37765] - Changing the order of calling events for fields. FieldsHelper.php
- Closed
- 9 Mar 2023
- Medium
- Build: 4.2-dev
- # 37765
- Diff
- korenevskiy:4.2-dev
User tests: Successful: Unsuccessful:
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 call the trego 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()
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Administration com_fields |
| Labels |
Added:
?
|
||
@laoneo what do you think?
Honestly the events should be stateless, means one event call should not depend on another.
I fully agree with you, calls should not depend on order.
And what do you think?And what if the programmer makes calls independent of the order of events, but at the same time makes calls dependent on the order of the fields.
Due to the fact that we think that the call of events should not be dependent on each other and thereby bind the hands of the programmer so much. That he will only have one way left. Do plugins fields and create field of order location that will overlap the calls order of these fields. The programmer needs to create a separate field for storing quantity and price for each product, and then create a separate field for displaying the sum of these all goods. But the second field should be displayed after all the fields in the order of priority set in the admin panel. If the order changes, then the final field will not show the correct amount.
As you can see, by imposing restrictions on the priority of calling events, we force programmers to create fields for materials in strict order.
Now I am doing 2 fields for the sale of goods, 1 field is used to store the quantity and price of goods, and another field is used to form an order event, with sending an application to the mail.
In addition, the field displays the price and quantity of goods. The field needs to be able to access the final data of the fields for all articles of the same plugin.
At the current time, in order to realize such opportunities, I have to load menu data in the plugin constructor, find component parameters, and then find the data of each article. This is a very long way to fulfill simple needs, which has pitfalls.
I am sure that if someone does such fields, then he has to do it in the same way.
Or creating 2 plugins of 2 fields, then to place them in the article in strict order. The 2nd field will display the total amount of the price. In this case, you must follow the procedure for placing fields in the article.
As you can see, both solutions to the problem are not very practical. the 2nd method imposes a restriction on the copywriter that requires compliance with the order of displaying fields.
This pull requests has been automatically converted to the PSR-12 coding standard.
HLeithner
- | Labels |
Added:
?
|
||
| Labels |
Removed:
?
|
||
| Status | Pending | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2023-03-09 03:39:18 |
| Closed_By | ⇒ | korenevskiy | |
| Labels |
Added:
PR-4.3-dev
|
||
Due to my confusion with the branches, I have recreated a new PR #40058
I inform all participants of the last PR
@laoneo @HLeithner
Changing the order will very likely break existing implementations of the event. I would even go that far to consider this as a BC break which should be at least considered for 5.0. Honestly the events should be stateless, means one event call should not depend on another.