Enhancement for (custom) listviews

[TimmiX88]

When enabling listview automatically all subitems are placed inside this list. This works well in general, for newsitems for example, but in some cases you also need other types of content underneath an overview page.

Example
When creating a jobs overview you create an overview page (jobOverview doctype with listview enabled) and underneath you have several pages for each job opening (jobDetail doctype). Because of the listview all these jobs are being shown in the listview. But then you might also want other pages underneath the overview page, for example an 'open sollicitation' page, an application form or general terms and conditions information page.

But now, because of the listview, these are also seen as a 'jobs' and shown in that (custom) list.

It would be useful if you can select one or more doctypes within custom listviews, so only pages of those doctypes are shows in the list. All other doctypes would then still be placed as a normal subpage in the pagetree.

[bjarnef]

This was also what I suggested in #10053

I think it would be best to explicit select content types which shouldn't be included in listview (and render as tree nodes) instead of selecting content types which should be included in listview as the first wouldn't affect what people already is familiar with and I think it wouldn't be a breaking change.

[TimmiX88]

Thanks for the reply, i did see that post but since it was closed i thought i'd open a new discussion to get some insights.

I personally disagree with your idea that it would be best to select doctypes to exclude from the listview instead of including them. I disagree for a few reasons.

1. you create a listview for a specific reason, so the list is often targeted at a specific doctype. Therefore you only want to add that one in most cases. It makes more sense to only add that specific doctype , instead of having to add 'all other' doctypes that doesn't directly relate to the listview you're working on. You're creating a listview, you're not creating the pagetree afterall.
2. It makes it easier to maintain. Once you add new doctypes along the way (or later in the future), you don't need to actively remember to add these new doctypes to to exclude them from all the listviews you have created.
3. It creates the possibility to extend the listview functionallity in the future to create more than 1 listview. Have a listview for child-documents of Doctype X and another listview for all child-documents of doctype Y and all other child-documents are just 'normal' pages int he pagetree.

I think above doesn't create a breaking change either. Selecting no 'Included doctypes' should fall-back to display all doctypes as it is in the current situation, so nothing changes.

Going a step farther than just the listview itself, I think the tricky part is how to visualize child-elements of items that are in a listview. They are currently not part of the pagetree either, so they are actually invisible/unreachable as far as I am aware. Maybe documents within a listview item shouldn't be allowed to have child-elements at all?. That's definetely a breaking change, so maybe not really desirable, but in a way it would make sense.

The alternative solutions are either to show potentional child-items withing the listview, or create some sort of 'pagetree' you have see when editing a document in a listview. But that gets quite confusing I think...

Another solution to fix that last issue, could be a simple checkbox on the custom listview configuration that says 'maintain default pagetree'. Once that is checked, you will get a nice listview, but the default pagetree will also be completely available. That way potential subpages are always accessible, and there is no restrictions based on doctypes.

[bjarnef]

It depends on the use-case I guess. For now developers are familiar with enable list view on a content type mean that all children (regardless on how many allowed child content types one have) will show up in the list view. List view doesn't necessarily target a single document/content type. The member list view is a good example of this. One could have several different member types, but the "all members" still show all types combined in a list view.

Another use-case it that one could a several different content types inheriting from a base content type (or use a composition). E.g. 10 content types sharing properties (used in list view columns) and besides that different specific properties for each of these. Furthermore one may have another content type (could be just one) which is allowed as child node, but this shouldn't show up in list view.
I think case it would be much simpler to select the single content type that shouldn't show up in list view instead of selecting 10 content types. The benefits with this approach is that it probably doesn't require a breaking change and the behavior on existing sites would work the same.

[hfloyd]

I actually think @TimmiX88 's suggestion that the doctypes be specifically included or if NONE are selected, then assume ALL are included, makes sense. The default behavior would then be like the current behavior of listviews (where ALL types are included).

In terms of this concern:

Another solution to fix that last issue, could be a simple checkbox on the custom listview configuration that says 'maintain default pagetree'. Once that is checked, you will get a nice listview, but the default pagetree will also be completely available. That way potential subpages are always accessible, and there is no restrictions based on doctypes.

What I have done when I want the functionality of a listview for the table UI on a "Parent" node, but don't want to hide the children items on the tree is that I create the custom listview and add it as a PROPERTY on the parent node type, but then I don't check the "Enable list view" option on the parent doctype. Then I get the best of both worlds.

[TimmiX88]

I totally forgot about this discussion, thanks for bringing it back to my attention.

The main reason i suggested (and favour) the opt-in approach is because that is also how the 'Allowed child node types' work. You have to actively select which children to allow. In my opinion it would make sense that when you create a list-view (for example for newsarticles) to define which doctypes to be part of that listview.

The idea of having to opt-out items seems annoying. If i create a new doctype (i.e a landingpage) I should not have to remember to go through all other doctypes that have acctually listviews and manually disallow them from appearing in previously created lists for specific doctypes. It seems counterintuative.

@hfloyd that approach of a property for the listview is a good idea. I haven't tried that before, but nice to see that being a workaround. I think think an extra setting in the listview configuration to hide/show the selected doctypes from this listview in the pagetree would be a little easier and more sustainable. It would also allow a future where multiple types of listviews are allowed on one doctype, where you for example might have a list of jobs and a list of newsitems.

You might want to hide the newsitems from the pagetree because they are standalone articles, but in case of the jobs you might want to also be able to see them in the tree since they might have subpages with extra information and an 'apply form' page which would not otherwise be visible within the listview. That would provide maximum configurability and usability.

[hfloyd]

Ps. Some info on Listviews in v14+:
#16628