why does max-render have JALL but maxresults only have J500

if i read correctly choice.js code there is no -1 for for max-results
but i could be wrong

maybe so but both fields are the same type and layout

not sure to get your point
but 500 max search results are far better than 10
or not ?
❓

I am just querying why we have different settings

I am just querying why we have different settings

The current JS setting (without the options) is:

• Max Result = 10
• Max Render = -1 (ALL)

Max Result does not support -1 (ALL) so it cannot be included in the list because it would not work.
Taking -1 (ALL) out of the Max Render list would limit the number of elements to a maximum of 500, so it would be a loss of functionality.
The only solution I see is to leave the 2 different lists.

Thank you for a logical answer

I have tested this item ✅ successfully on 760c029

I have tested this item ✅ successfully on 760c029

OK, it works.

I have tested this item ✅ successfully on 760c029

all right

I have tested this item ? unsuccessfully on 760c029

Changing firefox to dark mode immediately changes to dark mode in Joomla as well. With or without this patch.

I have tested this item ? unsuccessfully on 760c029Changing firefox to dark mode immediately changes to dark mode in Joomla as well. With or without this patch.

@crimle Are you sure you posted your test result for the right pull request (PR)? I don't see how this PR here is related to dark mode. Please check and report back, and either alter your test result back to "not tested" or ask us to do so for you. Thanks in advance.

I have not tested this item.

RTC

I wonder, why did you rename the field name? How do you take care about the "old" values, isn't this a B/C break then?

iirc i didn't want to touch com_fields
to limit the impact surface of the pr

I wonder, why did you rename the field name? How do you take care about the "old" values, isn't this a B/C break then?

Leaving form_layout and binding the 2 options to that tag does not work.
data-* options are loaded only with layout, this xml tag is also documented here, when the limit to fancy was introduced.

To make it work with form_layout com_fields has to be rewritten, which was not intended to be the goal of this PR

Not ready

The PR is not finished.
It can go in 5.x, if done properly there no b/c break.

Current XML modifications should be reverted. As we talked with @Razzo1987
And some more changes still need to be done.

I would add, that the changes should be done for list field first, and then copyed to sql field.
Because sql field extends the list field.

Hi @Fedik, the problem stems from the fact that to fix the bug and continue using form_layout the change on com_fields should be made. If I understand correctly from @alikon he does not feel confident in touching that part. If you can give him support I am also confident that using form_layout avoids b/c breaks.

i would like to make this happen for 5.x not 6.x, let's join together the effort then, the pr it's already open, better,
let's schedule a meet via mattermost on the weekend ? if you can

@alikon I made a PR to fix stuff alikon#49

thank you @Fedik

I have tested this item ✅ successfully on d736c88

Successfully tested with both List and SQL.

Tested with the example of the 12 months of the year and used the combinations:

• Max Results: 10, Max Render: ALL: He behaves as he always has
• Max Results: 100, Max Render: ALL: Show the 12 months by searching "month" (there are less than 100)
• Max Results: 5, Max Render: 5: Show only 5 months, also by searching "month"
• Max Results: 100, Max Render: 5: Show only 5 months, by search it show all the 12 months

Another test: if I set the fancy layout before applying the patch now it is retained. Thanks @Fedik

However, I propose to include j500 in the options.
For some cases 100 options might be few and we cannot put a consideration for ALL. J500 is 5x the current maximum and seems to me a good compromise.

However, I propose to include j500 in the options.

It will have a huge performance and usability issue, I think anything more than 20-30 is already to much.

I have tested this item ✅ successfully on cdc2480

However, I propose to include j500 in the options.

It will have a huge performance and usability issue, I think anything more than 20-30 is already to much.

I'll try to do a video, but I really don't think it changes much in terms of performance.
I have a SQL field that extracts 1500+ records and the latency is related to the query not the limits imposed by the fancy-select

I have tested this item ✅ successfully on cdc2480

RTC

Performance test

Create a SQL field with multiple values, for example:

SELECT concat(`TABLE_SCHEMA`, '-', `TABLE_NAME`, '-', `COLUMN_NAME`) AS value,
               concat(`TABLE_SCHEMA`, '.', `TABLE_NAME`, '.', `COLUMN_NAME`) AS text
FROM `information_schema`.`COLUMNS`

Test 1: Form Layout = HTML Select

Test 2: Form Layout = Enhanced Select, Max Result = 10, Max Render = All

Test 3: Form Layout = Enhanced Select, Max Result = 500, Max Render = All

Personally, I do not observe significant performance changes in user experience between 10 and 500

@alikon I think is missing the new option on plugins/fields/list/list.xml.
I have done alikon#54 on your branch ;)
Before merge check if the name must be "form_layout" or "layout" (in my PR and in this one)

Sorry @Razzo1987 , but 6 second for the form rendering I would call it disaster ?
And imagine User add multiple of this fields?

Note: changes in this PR does not affect SQL limit, only the rendering limit for choices.js

Sorry @Razzo1987 , but 6 second for the form rendering I would call it disaster ? And imagine User add multiple of this fields?

Note: changes in this PR does not affect SQL limit, only the rendering limit for choices.js

Correct, but the 6 seconds is because the form loads 1500+ items in the list.
In fact even with HTML Select the time is that. the fact that I set the search limit to 500 did not affect with other lag

Correct, but the 6 seconds is because the form loads 1500+ items in the list.

And that what you should never do, ever ?
You may have fast PC, but someone have older, and it may take a minutes just to render.

the fact that I set the search limit to 500 did not affect with other lag

Yeah, well, but I still do not like it, it just unusable, and fancy-layout allows to search already ?

I have tested this item ✅ successfully on 058087f

Successfully tested with both List and SQL.

Tested with the example of the 12 months of the year and used the combinations:

• Max Results: 10, Max Render: ALL: He behaves as he always has
• Max Results: 100, Max Render: ALL: Show the 12 months by searching "month" (there are less than 100)
• Max Results: 5, Max Render: 5: Show only 5 months, also by searching "month"
• Max Results: 100, Max Render: 5: Show only 5 months, by search it show all the 12 months

Another test: if I set the fancy layout before applying the patch now it is retained.

I have tested this item ✅ successfully on eb1af78


I made the following tests (using the SQL query with months):

• Max Results: 10 - Max Render: ALL - Search string: empty --> I see the list complete
• Max Results: 10 - Max Render: 5 - Search string: empty --> I see the first 5 elements in the list
• Max Results: 10 - Max Render: ALL - Search string: "month"--> I see the first 10 elements in the list
• Max Results: 25 - Max Render: ALL - Search string: "month" --> I see the list complete

I changed the query to obtain a resultset with 26 elements:

• Max Results: 25 - Max Render: ALL - Search string: "month" -->I see the first 25 elements in the list
• Max Results: 25 - Max Render: 10- Search string: empty -->I see the the first 10 elements in the list
• Max Results: 100 - Max Render: ALL - Search string: "month" -->I see the list complete

The patch worked as expected.

I made the following tests (using the SQL query with months):

• Max Results: 10 - Max Render: ALL - Search string: empty --> I see the list complete
• Max Results: 10 - Max Render: 5 - Search string: empty --> I see the first 5 elements in the list
• Max Results: 10 - Max Render: ALL - Search string: "month"--> I see the first 10 elements in the list
• Max Results: 25 - Max Render: ALL - Search string: "month" --> I see the list complete

I changed the query to obtain a resultset with 26 elements:

• Max Results: 25 - Max Render: ALL - Search string: "month" -->I see the first 25 elements in the list
• Max Results: 25 - Max Render: 10- Search string: empty -->I see the the first 10 elements in the list
• Max Results: 100 - Max Render: ALL - Search string: "month" -->I see the list complete

The patch worked as expected.

I've restored @Razzo1987 's test result in the issue tracker since the commit which invalidated the test counter was just a clean branch update.

@Quy If you update the branch of a PR which has human test results and the branch update is clean without any merge conflicts to be solved, could you then restore the test results of the users by using the "Alter test" button in the issue tracker? Thanks in advance.

Ah I just see it was ready to commit already.

Ah I just see it was ready to commit already.

Yes, it had remained in RTC even after the changes 3 days ago, I don't know why.
I wrote to Roberto today if he could redo the tests that have done during PBF ;)

Well we have now 2 tests again which are valid, so RTC is again valid.

as there is no interest

redone and rebased on 5.3 pr #44794