AI OnAI Off
What's the best solution for managing 1,000+ child pages under a single parent?
These publications, are they imorted from an external system, or are the client supposed to manually create and work with the pages through EPiServer?
Jun 16, 2011 9:04
I would have made myself a PageAdaptor
<adaptercontrolType="EPiServer.UI.WebControls.PageTreeView"adapterType=
, and added some logic here, if the children count was larger that 50, and grouped them in 50 blocks. This way the url's are the same
Jun 16, 2011 9:07
Guess you could override
protected virtual HierarchicalDataSourceView GetData(string viewPath)
It seems that all calls to get the tree goes throu here :)
Jun 16, 2011 9:39
@Alf: Initially imported from an external system, but they add new ones weekly from the interface.
Jun 16, 2011 14:45
This is a time consuming option, but is there a reason not to make a "PublicationsContainer" template that in admin mode displays a nice layout of them with some javascript filtering options?
Never display the child item directly, but find it from the container and give an edit link there?
Jun 16, 2011 18:45
Is there a best practice for handling large amounts of pages under a single parent page?
For example, my client has a series of publications which are all published under the same parent -- 1,238 of them. This causes lots of problems with the admin interface. When the parent is expanded, you have to wait a couple seconds while all 1,238 are listed in the tree. Then, this "takes over" the tree. Since child pages in the tree do not paginate, you can scroll for many dozens of screens in either direction. Jst trying to get back to the parent to collapse it is difficult, and since you can't really see the parent anymore (or the parent's sibling -- the page below the long list), it gets hard to figure out what level of the tree you're on. It's unweildy, to say the least.
I know what you're going to say -- you need to subdivide them, into year and month folders or something. I understand this a common scenario, but my client doesn't want to do it. Year and month folders just don't make any sense in this context, and they're concerned about URLs -- they're trying to preserve some existing URLs, and moving pages around the tree changes the URL.
My client has come away from this situation thinking EPiServer's a little goofy in this regard. Their reaction is to wonder how a CMS that does everything else so well is so bad at something as simple as this. Granted, this isn't a deal-breaker issue, by any stretch, but they would still like it to work how they want it to, and not live with this odd limitation.
I experimented with something drastic --
Bind an OnLoadedChildren event. If the inbound request is to "EditTree.aspx," clear e.Children collection and add back a single page ("No Link, Just Text") with the title "Too many pages to list." So, when they try to open a node with 1,238 children in the tree, they just see this notice underneath it. Then, have a tab in the Edit Panel that lets them search through the children of that page in a GridView.
Amazingly, this worked. But while it solves the main problem, you still have problems in other situations when you use the tree (selecting a page for a Page Reference property, selecting a page to populate a Link Collection, etc.).
Any best practices here? Has anyone run into the same problem, and how did you solve it?