[4.0] Fix the new emptyState feature

[bembelimen]

The emptyState feature is really nice, but the database query has two issues:

Steps to reproduce the issue

First issue:

Go to a model and add the following code:

	public function getTest()
	{
		echo $this->_getListQuery()->dump();

		$this->getIsEmptyState();

		echo $this->_getListQuery()->dump();
	}

Now call in your view:
$this->get('Test');

2nd issue:

have a query with 2 from or joins, grouping, having, etc.

Expected result

First issue

twice the same query

Second issue

The method is generic enough to work all the time (Imho clearing the query is per se wrong, it should build up the query...but that's my opinion)

Actual result

First issue

different queries

Second issue

It fails on so many instances (Joins, Grouping, several froms, ...)

Additional comments

The emptyState check changes the original query instead of making a clone (which is still broken) or do a normal new query with the correct syntax. => also check _getListCount(...)

[richard67]

We could fix issue #33386 with use of the empty state feature, too, if this issue here is solved.

[PhilETaylor]

Not really a release blocker - as you can simply add "return false" at the top of the isEmptyState function and be done with it and release Joomla 4 without this feature. The feature is only a smoke screen, all previous behaviour is still there.

Everyone seems to have their opinion on what should be in that function, but I have not seen any real concrete examples from people yet.

getIsEmptyState() method is written to check the empty state of the last SQL run. (Ie removing any limits from the SQL and counting the number of rows). It is not written to check if a model is an empty state, because Joomla abuses models with huge queries with multiple joins. As written, the query in getIsEmptyState() method does exactly what it was designed to do, that is, to take the last query run, clean it up, and to run it again to return a count of rows.

Used like that, the method is working well.

Used any other way, with false assumptions, like the one you are reporting in this issue, will result in different behaviour.

Issue 1 - if you are going to misuse functions then its up to you to understand the knock on effect. _getListQuery is a protected method for a reason and getIsEmptyState() method was written to directly manipulate the LAST query before it was run.

Issue 2 - It does not "fail on so many instances". All reported "instances" have already been fixed within hours of being reported.

_getListCount literally does something similar to the code in getIsEmptyState.

[richard67]

See also #33453 (comment) .

[PhilETaylor]

However, since it is a Public method, we could not assure that. For a public method like that, developer could call it anytime they want and not depend on the calling of other methods.

Which again comes down to the DEVELOPER not understanding that getIsEmptyState is working on the LAST QUERY RUN.

There simply is no quick an easy way to say "Hey Im on the Articles page, are there no articles in the db?" in a GENERIC AND REUSEABLE way.

I can see us now having to pull up the getIsEmptyState and have to write a different method for each and every component just to satisfy the "new" requirements developers now have of this feature. (Same as we have done for Categories and tags where getIsEmptyState is in the Model for the component.... hardly a nicer solution.

[joomdonation]

Which again comes down to the DEVELOPER not understanding that getIsEmptyState is working on the LAST QUERY RUN.

That mean we don't understand how to write proper public API method. As mentioned, developers should be allowed to call a public method anytime they want. A public method call should not depend on other method call.

We will have to find a way to solve this issue properly (I mean we, not you work on it alone)

[PhilETaylor]

So you want to disconnect getIsEmptyState from the previous SQL run, that's cool - just means we now need to hand craft a SQL for each and every component..

[bembelimen]

You know, we're all in favour of the emptyState feature, we just want to get it stabilized. So I'm not sure why you're against looking for a nice solution which makes everyone happy but slashing out against that "stupid developer" (yeah, my words, not yours).

_getListCount works on a copy of the original query, so it's not the same, but can be fixed very easy.
This would also fix the issue @joomdonation mentioned.
The clear-approach is, in my opinion, the wrong one because there are too many things to consider. So perhaps by discussing we find a better solution....if not then not...

So we're all karma here....

[joomdonation]

So you want to disconnect getIsEmptyState from the previous SQL run, that's cool - just means we now need to hand craft a SQL for each and every component..

I did not say that. At least we should borrow some ideas from getTotal method and continue from there

[PhilETaylor]

Im not against anything, but equally I have not seen any concrete examples from anyone that take every scenario I have already had to play through over several weeks to get this where it is today - which is merged and working.

[PhilETaylor]

At least we should borrow some ideas from getTotal method and continue from there

Dont you think I tried that. It doesn't work because again it relies on the list query - and therefore if you select a Tag and you get no results you get empty state, when the table is not in an empty state.

[joomdonation]

Dont you think I tried that. It doesn't work because again it relies on the list query - and therefore if you select a Tag and you get no results you get empty state, when the table is not in an empty state.

We must find a way. If not today, then tomorrow. We still have time.