One of the advantages of such a basic listing block is that it is fairly easy to customise. If it was more customised at the start, while it would cover more uses, it would also make it more difficult to extend for other uses that went in a different direction.

If a new page list were to be incorporated into 5.7, it should be in addition to the current page list block, not instead of. The current block has too much history behind it. Perhaps that is where the 5.7 'Grid' block comes in.

There are lots of page list templates and full block alternatives in the marketplace, some free and some paid.

One of the things that I feel limits the scope of extending blocks is that one controller can have many templates, but you cant use one template with many controllers without copying code. In the case of a page list, where the data passed between the two is essentially just a list of pages, the flexibility would be massively increased if controllers and templates could have a many-to-many relationship. So you could pick a controller that selects pages the way you want and match it up with a template that displays them the way you want.

I have tried to get round such a limitation with my Universal Content Puller and Uber List addons. Both can use any content block template as a 'wrapper', even if it is only a background and border. However, limitations of the way addons can be interdependent in the marketplace means that the wrappers are not interchangeable, so I can't use the Formigo Containers wrapper that plugs in to Universal Content Puller with Uber List (that is a small job on my very long to-do list).

thanks for the insight. not sure i follow though. in what way would it be more difficult to extend the page list for other uses if these things were added?

the improvements i'm suggesting would only affect the page list collection. perhaps also the sorting option but it wouldn't be too complex to add backward compatibility for that.

maybe i'm just not sure what you mean by extending a block? do you mean using custom templates or creating new blocks that inherit the page list controller etc?

not sure i'm a fan of adding these things to a new block because it still very much is a page list and nothing else. the current page list has 0 filtering options (except for is_featured).

btw, it's come to my attention that Page List+ does what i'm asking for so i'll most likely use that from now on. just feels silly to use a custom block for something that i feel should be core functionality considering how common the block is. what's next, a custom content block? :)

If you want one, there are plenty of custom content block alternatives :)

I was using 'extend' in a generic sense, to encompass any means of extending functionality (ie. not specifically class inheritance).

Page List + provides a good example of where a many-to-many relationship would be useful. Suppose I want the listing/filtering capabilities of Page List +, but also want the display template from one of Dojo's folio templates for Page List. At the moment I have no option save copying the template into a template for Page List + (assuming there are no functional incompatibilities). With a many-to-many mapping between block controllers and block views, I would simply be able to connect the two together.

Having said that, there are view templates for the Page List block will work with Page List + when copied across, but some marginal functionality gets lost in the process.

for the many-to-many scenarios, i usually use elements which works pretty well. so like, both block #1 and block #2s view template just includes a PackageElement call to the same element file. but yeah, of course, this only works when you have total control of both blocks, ie, they are both custom made blocks that you have made yourself and they're both in the same package. so it wouldn't quite cut it in the general sense that you're talking about.

in the more general sense, i'm not sure i see how it would work logically. sense a view/template relies on certain variables to be available ($controller->set), by letting a view/template work for several controllers there's no logical way of knowing if these variables will be available or not. it's already confusing and uncertain the way it is now since there's no definition of what's being sent/set to the view. involving more controllers would only make it worse in that sense.

Yes, it could only work for very specific circumstances. At its simplest, any content block template should work with an html block (and vice versa). Something as simple as that would have more than halved the number of files @enlil needs to maintain for Transparent Content.

Page List is a situation where it could work with more complex blocks. A controller provides a filtered list of pages and some instructions about pagination. A view displays that list. Autonav could do similar.

Perhaps a block controller could declare a list of other block types it supports templates from. So any alternate page list block controller could declare that it also supported templates from Page List.

Perhaps a concept of Block Sets or Block Classes, where any block type controller in a Block Set can potentially use any template of any other block in the set.

I expect there would be situations where edge functionality does not translate. So the criteria would need to be that the main functionality (a list of pages) was supported.

Or maybe the other way round, perhaps a dashboard interface (like for installing single pages or managing block types), where a site owner can cross-connect templates (high chance of doing something lethal), or an api where a package controller can cross connect templates within the package to multiple block types, though that scenario can also be solved by your multiple template shells + one element approach.