You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 16, 2021. It is now read-only.
In an application with many children per node the treebrowser api (resource) answers with an 500. No matter if it is an timeout at the database ore on server process. But there are case where the list of children is that long, that it is hard to handle through the API and the the tree afterwards. the User won't see the complete result at all. We could go ahead and reduce nesting depth to 1 for this list. That would work, but how to know if there are to many nodes? To many siblings or to many children of one node.
So an idea would be to load 10-20 nodes at all, and give some ... to reload the next. Especially the input field would be very happy, where we need the parent only (mostly)
So my idea would be to have:
/cms/
content/
pages/
..... # here could live pate 1-9
page 11
page 12
page 13
page 14
page 15
page 16
page 17
page 18
page 19
page 20
... # here could live page 21 - XXX
The text was updated successfully, but these errors were encountered:
yeah, that is a real issue. what do other tree view tools do to solve this? should pagination happen in the tree as a virtual level of the tree - with extremely long trees, even the number of pages can be too large? or should the pagination be a "endless" scrolling window under pages that loads pages as you scroll up or down?
Symfony packages
SF4,but does not matter
Symfony CMF packages
all
Subject
In an application with many children per node the treebrowser api (resource) answers with an 500. No matter if it is an timeout at the database ore on server process. But there are case where the list of children is that long, that it is hard to handle through the API and the the tree afterwards. the User won't see the complete result at all. We could go ahead and reduce nesting depth to 1 for this list. That would work, but how to know if there are to many nodes? To many siblings or to many children of one node.
So an idea would be to load 10-20 nodes at all, and give some ... to reload the next. Especially the input field would be very happy, where we need the parent only (mostly)
So my idea would be to have:
The text was updated successfully, but these errors were encountered: