#36636

It's hard to imagine that it was previously impossible to dynamically create fields in PHP. This feature is the main problem for developers.
.
But now this field can be created dynamically in PHP.

There no problem to use any field class on it own.
Example for text field:

$field = new TextField;
$field->setup('<field name="blabla"/>', 'some value');
echo $field->input;

// Or just:
$field = new TextField;
$field->setup('<field />', 'some value');
echo $field->input;

Each field in Joomla is require XML, whole Form API based on it.
No need a hacking around.

But type SimpleXMLElement of the $element
public function setup(\SimpleXMLElement $element, $value, $group = null)

yeah, well, but the idea is the same:

$field = new TextField;
$field->setup(new SimpleXMLElement('<field />'), 'some value');
echo $field->input;

yeah, well, but the idea the same:

$field = new TextField;
$field->setup(new SimpleXMLElement('<field />'), 'some value');
echo $field->input;

That's how it works. Is it OK to create an unnecessary object?

I watched how the FIELDS component works. The plugin of this component creates a complete object XML form similar php object . In order to then get a regular object back from it. Thus, it is created XML object from a regular object, and then a regular object is created from XML. All fields are subject to transformation. each property is converted to an attribute, and then the attributes are converted back to properties.

Well, now you can see that by creating a field plugin for an article, this object will be converted to XML and vice versa. And the field plugin contains the usual other field. So to create a field in the article. There will be a four conversion of the object to XML and back, and then again from the object to XML and back to load the usual field into the plugin field.

I was creating my own plugin fields for articles. And also created another field. I can't pass data from the plugin to the field. Since it all happens by conversion via XML.
Thanks a lot for the experience. I will use it in the future. But I think that dynamic fields should work intuitively.

@Fedik
How do you color code?

@Fedik @richard67 @brianteeman
And who has the authority to say whether the Joomla API will support the creation of tabs, a set of fields, and just fields dynamically in the future, without conversion to XML and vice versa? This is very limiting to create multifunctional components based on materials.

@korenevskiy What do you want from me? I‘ve only closed your issue because that’s our regular procedure, close an issue when there is a PR which claims to solve it. You should have done that yourself and should have mentioned the issue in the PR description.

@richard67 he is looking for your approval on this PR

@richard67 he is looking for your approval on this PR

I will not approve that.

The discussion did not take place.

There is simply nothing to discuss for me because I am the wrong guy. I am not a field expert. When I have something to say because I have some knowledge on it, I will say, but when I have not much knowledge I prefer not to have to say something :-)

There is simply nothing to discuss for me because I am the wrong guy. I am not a field expert. When I have something to say because I have some knowledge on it, I will say, but when I have not much knowledge I prefer not to have to say something :-)

I thought you were not the most important here, but you are the third oldest. I have seen your participation in many places. And what are you a master at?

Is it OK to create an unnecessary object?

Yes, every Joomla field require to have the XML element.
You can pass any supported data to your field, just make sure you call setup() first.

How do you color code?

It is MD markup

And what are you a master at?

I have a master degree in Electrical Engineering :-)

I have a master degree in Electrical Engineering :-)

I am also an electronic engineer, and I can collect ZX-Spectrum.
And in Joomla, what are you an expert in?,
I'm just sorry that I needlessly distracted you. In the future, I will close the issue before doing PR in the future. I promise.

And in Joomla, what are you an expert in?

I can find bugs by their smell :-)

Yes, every Joomla field require to have the XML element.
You can pass any supported data to your field, just make sure you call setup() first.

These requirements described by you are the current requirements. Each code must support these requirements. But the requirements can be changed if the requirements complicate the code unnecessarily.

Programming language developers have come up with interfaces to respect typization. But we are in a transitional moment to the world of typization, but we convert everything to XML and back. I wrote one cool field. The field has the form of a table, each cell is a different field (text, area, select, radio button). There can be any other field in the table cells.

A new table field, can take data from SQL, or just JSON, Rows can be created, Each row is draggable and removable. Then I create a plugin field for the material. Now I need to add the table field to the plugin field. Having written the field path and loaded the typization, I could not pass an array of values to the table. Since the FIELDS plugin converts all fields to XML FORM in order to then create PHP objects based on XML FORM, it's hard. I ran into the problem that everything is done through one place, through XML.
This happens at different levels of the materials component. Since we are gradually moving towards typization, maybe we should reconsider whether there are requirements to always contain XML in the field?
By creating a multi-level field that contains other fields that may contain other fields, this creates problems.

@korenevskiy

XML => DECLARATIVE (here's a config file XML, json, whatever)
PHP => IMPERATIVE (here's the code that creates the field like @Fedik shared above)

What you're demoing here is the removal of the XML parser step. Is that so much a limiting factor here? If you want to improve the Form/Fields code just composer install Symphony Form (whatever the package name) and connect the missing links...

@korenevskiy

XML => DECLARATIVE (here's a config file XML, json, whatever) PHP => IMPERATIVE (here's the code that creates the field like @Fedik shared above)

What you're demoing here is the removal of the XML parser step. Is that so much a limiting factor here? If you want to improve the Form/Fields code just composer install Symphony Form (whatever the package name) and connect the missing links...

@korenevskiy

XML => DECLARATIVE (here's a config file XML, json, whatever) PHP => IMPERATIVE (here's the code that creates the field like @Fedik shared above)

What you're demoing here is the removal of the XML parser step. Is that so much a limiting factor here? If you want to improve the Form/Fields code just composer install Symphony Form (whatever the package name) and connect the missing links...

Declarative and imperative approach, both are good. But, in the problem I described, I showed that multi-level transformations take place back and forth.
The declarative approach is a way of programming, but it is not a way of storing objects.
If we pay attention to WPF C#. We will see XAML is a form of writing code, but the objects themselves are the same for any method. There declarative objects in the text are converted to C# objects when compiled. In our case, we do not have a single object form, we will not only write declarative code, but we will store it after the program is launched. We convert data back and forth many times. On the other hand, the support of the imperative method is not an opposition of the approach. I'm not asking you to delete the SETUP method. Let's be honest If I create a field in PHP and put XML in it. Then the imperative approach says that the XML I put is automatically the node of the entire XML FORM. But this is not the case, nothing like this happens, creating a separate field and putting a field string in it, this declarative object is not included in the XML form at all and is no longer used. It does not attach to a common XML object. Unless this field was originally in a shared XML object.

And also, all field objects live by themselves separately from XML, even though they are in each other. Let's look at the Register class. It easily loads declarative data.
The penultimate problem is that when rendering, XML is converted back to an object, and then it is converted to HTML. Even from the point of view of declarative objects, we will still have to convert everything to HTML via PHP.
It might be useful to navigate through the XML object model like SQL queries through the XML tree. We have NOT implemented this, but even in this case we should have data isolation.
XML does not stand up to criticism as a data warehouse, it is not ideal for supporting big data storage and fast navigation through this data. If we continue the declarative idea, then we should inherit the JTable class from XML so that the declarativeness is complete, so that the Database data is converted directly to XML. We also need to make the session storage in the form of an XML object.
In WPF C#, declarativeness is typed, there are types and namespaces at the XML level. In order for Joomla to expand into the corporate sector, it is necessary to move towards typing. Storing data in XML is a step back from typization. The whole framework strives for typing, but we will store the data in untyped XML. What's the point?

1.I suggest using XML only when loading data into the SETUP method.
2.Store data in properties similar to JRegistry.
3.Add the ToXML method for the fields.
4.Add a dispatcher to the HTML code of the tabs of the material editor to add your own tabs with PHP code.

Let's not confuse declarative code in a file with declarative objects in RAM. If we stop confusing, we won't shoot ourselves in the foot. The imperative and declarative approaches have advantages and disadvantages, let's take the best out of both, and not replace one with the other by creating new problems by solving others.

I closing it, because it does not fix anything.

I closing it, because it does not fix anything.

Have you personally checked how these PR fixes work? This code works as I described it here:

$field = Joomla\CMS\Form\FormHelper::loadFieldType('text', true);
$field->name = 'user';
echo $field->renderField();

Why did you close the PR without checking? But even if I had mistakes, I could make new corrections. But you just took and closed the PR.

I already wrote, that code is incorrect, you have to call setup() for every field, as long as Joomla Form API use XML.

$field = Joomla\CMS\Form\FormHelper::loadFieldType('text', true);
$field->setup(new SimpleXMLElement('<field />'));
$field->name = 'user';
echo $field->renderField();

I already wrote, that code is incorrect, you have to call setup() for every field, as long as Joomla Form API use XML.

Okay, I get it. The Setup() method is the second constructor of the field. It is not clear why 2 constructors are used in the fields. What is the purpose of using the method executing the second constructor? What is it invented for? The Setup method should logically be optional for loading XML. But if it is mandatory, then why was it invented? Why not immediately pass XML to the field constructor?
PS That's a good question.

because:

$field = Joomla\CMS\Form\FormHelper::loadFieldType('text', true);

It doesn't explain anything. Such a method could be exactly XML as an example.
an invented example:

$field = Joomla\CMS\Form\FormHelper::loadFieldType('text',  new SimpleXMLElement('<field />'), true);

This loadFieldType() method is a wrapper of the field class. You told me the reason that it's because of the wrapper, but the wrapper is just a short form of a call, it's just a helper. Your statement is similar, that the fire burns because the smoke rises.