[J4]Let's make JInput easier

[korenevskiy]

Dear colleagues. A few years ago, I thought that writing long chains of classes to refer to simple entities is the culture of programmers.
Example:
JFactory::getApplication()->input->get('username');
But I'm sitting and thinking, why should I put my pants over my head?
Why not use calling query values in a similar way but in a simple way:
JFactory::getInput('username');
Arguments:

1. This is the JFactory class meaning it gets access to the most common CMS resources.
2. In 99.In 9% of cases, we use a simple scheme for obtaining query values. For example, an easy and simple module to create. We often write modules, our modules are simple and do not require anything special. 99.9% of the modules are exactly like this. And they require the simplest way to get values from INPUT.
3. Such writing is fast, simple, Even when writing components and plugins, it will completely satisfy all needs.

But if you need to perform type checking, but you can write like this.
JFactory::getInput('username','string'); - By specifying a STRING, CMD or other security modifier.
It's simple, clear, easy to read.
The main task of PSR is the ease of code readability. Since the code will always be read in the future, the PSR rule solves this problem. So why is it so difficult to get INPUT values?

And if you need to specify the INPUT value in the condition?

if(JFactory::getApplication()->input->get('username') =='Guest' || JFactory::getApplication()->input->get('username') =='Registered'){
..
}

Developers write such checks everywhere. We compare the INPUT values many times everywhere. You can see how difficult the code becomes to read.
And now the same thing, but briefly.

if(JFactory::getInput('username') =='Guest' || JFactory::getInput('username') =='Registered'){
..
}

[chmst]

You are writing this for Joomla 3. - I doubt that there such generic things will be changed now.

In J4.0 much has changed.

[korenevskiy]

I write for Joomla 4

[korenevskiy]

I don't understand what's dangerous here.

class Factory{
   public static function getInput($param='',$filter = 'CMD'){
	if(!isset(JFactory::getApplication()->input)) 
		return null;
	if($param == '')
		return JFactory::getApplication()->input;
	return JFactory::getApplication()->input->get($param,null,$filter);
   }
}

There is nothing here that can lead to an error,
I'm just calling another method in the method. If an error appears, it will not be the fault of the method, but the fault of other classes and methods inside this method. If an error is possible, then it is only a typo error, no more.

[korenevskiy]

If the community supports me, I will do PR in J4.

[korenevskiy]

I noticed that a lot of methods in JFactory have become obsolete. At the same time, it is proposed to use similar methods from JApplication.
Does Joomla have a way to abandon JFactory completely?
Dear colleagues, please tell me what is the alternative to calling Application quickly, so that you do not have to write such code:
JFactory::getApplication()
But is also deprecated.
JAplication::getInstance();
It is suggested to use:
\Joomla\CMS\Factory::getContainer()->get('DatabaseDriver');
or
Instead of JFactory::getsession();
It is suggested to use
JAplication::getInstance()->getSession();
But then JAplication::getInstance() also deprecated.
In the future, we will not have fast and simple tools for accessing the session, the server, the database, and so on?
It turns out that we will call containers and write code to call data on 2 lines?

[korenevskiy]

Why such difficulties?, the tools should be simple and easy. Even if there are high-tech developments inside

[Fedik]

This will never happen. We should use containers, and $app-> to access to $app related stuff (input, document etc).

I don't understand what's dangerous here.

It is not dangerous, but hard for testing, and some other stuff I not remember.

In the end it is OOP, not procedural programming

[korenevskiy]

Containers are good. But it is not clear why it is impossible to make an Assistant for the most frequent functions.
JFactory was the assistant.
jQuery for JS was a good helper, it made complex things simple.
The introduction of containers in Joomla should not mean complicating the API.
If this trend continues, then various APIs with helpers will appear on the Internet to simplify working with the JOOMLA API.
The very essence of the framework is to make complex things simpler.
That's exactly what it is at the same time OOP and at the same time procedural programming.

In the end it is OOP, not procedural programming

Any student familiar with HTML layout should easily create modules, and if the layout designer is forced to use OOP to create modules, will it be good?

The FrameWork for managing the Joomla FrameWork will appear on the Internet.

[korenevskiy]

@Fedik @chmst
I want Joomla to become number 1 among CMS.
Certain certain things in Joomla must be procedural unambiguously. But this does not cancel the OOP.
Creating modules should not require OOP from the user. Absolutely not.

[brianteeman]

Pointless discussion - never going to happen

[korenevskiy]

I'm not saying that we need to return JFactory.
But I claim that there should be a procedural Helper for calling the Session, Inputs, Others.
If there is no analogue of such a procedural assistant, I think it will be a sad outcome.

[korenevskiy]

This is very similar to how developers write software for themselves. Forgetting that Joomla has programmers, students, beginners, and those who are just a designer, whose task is to be able to fix an error in the code, without understanding technologies at all.
Colleagues, remember yourself when you just started writing code in PHP. For you, the creation of the module was an achievement.
.
Using OOP is great, but I see that the extreme is coming.
PHP has implemented typing similar to C#. But if PHP would make it mandatory to use types like C# for all variables. That would be death.
The Joomla api does the same as PHP would make it mandatory to define the type for variables. But PHP does not make types mandatory. And Joomla makes OOP mandatory.