ListPart - Allow setting for PagerSlim or FullPager

[deanmarcussen]

Discussed during a meeting, we should optionally provide a setting, for which pager to use for the `ListPart, in the front end.

i.e. PagerSlim or Normal

PagerSlim by default

/cc @urbanit

Note. we would probably keep the pager slim for the admin part of the list. It could be an option as well, but the note for anyone who implements is to remember the service is used for many places.

[urbanit]

Could be an option for admin as well.

[Skrypt]

Basically a Pager can be moved to a PagerSlim but not the opposite. Because, the Pager need a total count of records to be rendered properly. So, this would require that we have a specific method to return record counts from either Lucene or DatabaseProvider X. We have this, because I added it a while ago. Now, from either a Shape or a Controller this could be done.

[deanmarcussen]

To achieve this the IContainerService should have a new query method/overload, which accepts a Pager rather than a pager slim.

The current QueryContainedItemsAsync is probably complicated enough, that it's worth a second overload QueryContainedItemsAsync(Pager)

The viewmodel itself takes a dynamic property called Pager, so it's just a matter of having the second query, the ViewModel itself won't need to change, just a couple of settings inside the Driver

The second query will actually be simpler, as it doesn't need to calculate based of ticks, it can calculate of the supplied page numbers w/ skip and take, and just needs to respect all the other properties (and then make a second query for count probably)

[Skrypt]

LuceneQueryResult always returns a Count. Though the SQLQueryResult doesn't because it would need to do a second query all the time. So, the Pager could be using a LuceneQueryResult too. We need to have a way to use either a second SQL Query to retrieve the count or not.

[deanmarcussen]

I'm not sure why you are suggesting lucene here @Skrypt ?

Right now the ListPart has no dependency on lucene, it is simple a ISession query.

(so yes it would end up being a second ISession query to get the count)

It could be an option to replace the ContainerService with a a lucene version, which people could use, as an alternate if they wanted, but I would have thought this could be an option, not a default thing?

[urbanit]

Maybe I 'm wrong but @Skrypt proposes that because we do not have the total count on ListPart and we need a second SQLQueryResult. On other hand, Lucene can return both in a single query.

[Skrypt]

Right, exactly what I'm suggesting. But, here it's only for Lucene and when you use an admin Lucene Query. Here, if we want to make this work with a common Session it would require the same kind of helper class. Though, when you create a Liquid Template you will use 100% of the time an admin Query template to do so. So it's worth thinking about both use cases. Razor templates vs Liquid templates.

[deanmarcussen]

Ok, I hear what you're suggesting.

The ListPart currently only works with a ISession, through the IContainerService, which is essentially the helper service.

The query is made in the Driver. So the ContentItems are populated before it gets to the view.

(very unlike other parts like the ContentPickerField)

You can't really make a liquid template with a query in it (or if you do, the Driver query will continue to happen, so you actually end up with two queries) - because the query is already made.

So for this issue, of how to use the FullPager I still suggest that the helper service to adjust is the IContainerService

For the issue you're raising @Skrypt, i.e. how to do this through the admin, that is a seperate issue, but also well worth resolving.

For most of our sites, I disable the standard driver, and replace it with one that does not make the query, so that I can query in the view, so I can apply different filters etc to the query.

I could see another setting on the ListPart - QueryContentItems as to whether to use the current helper service (would make any changes non breaking)

But equally either no one has realised the multiple queries or no one is trying to do it? Not sure.

[agriffard]

Reminder to, at least, triage this issue.

[github-actions[bot]]

We triaged this issue and set the milestone according to the priority we think is appropriate (see the docs on how we triage and prioritize issues).

This indicates when the core team may start working on it. However, if you'd like to contribute, we'd warmly welcome you to do that anytime. See our guide on contributions here.

[github-actions[bot]]

We triaged this issue and set the milestone according to the priority we think is appropriate (see the docs on how we triage and prioritize issues).

This indicates when the core team may start working on it. However, if you'd like to contribute, we'd warmly welcome you to do that anytime. See our guide on contributions here.