Trees refresh way too often - (Slows site editing down)

Navigation trees do not need to be reloaded every time you click on a new resource, element or file to edit. Those trees should only be reloaded when absolutely necessary or there should at least be an option to completely disable automatic tree refreshing, in other words a system setting that changes tree refreshes from automatic to manual.

What should happen when you click on an item of the tree is that only the right side of the manager should be reloaded with the new resource, element or file interface. This would be much faster than reloading the entire page and rebuilding the tree etc, without any reason for it.

I know that this would significantly increase the speed of page editing. Slow downs on editing a couple of pages is inconvenient, slow downs on editing 20 or 30 pages is unbearable.

Not sure if there is a modification request already for this, but this should be a high priority change as it will significantly impact the performance of the manager interface.

I am using MODx Revolution 2.0.4-pl2 on Firefox 4.0 Beta 7

After searching the bugs website, I believe that there is a bugfix request that corresponds to what I have described above it is located here - http://bugs.modx.com/issues/2510

I put my vote for upping the priority of this bug fix

1. Evolution uses frames, hence why it can do the partial page refreshes.
2. Revolution does not use frames (as frames were one of the #1 complaints against Evolution back pre-revo)
3. Moving Revolution to frames would break features, such as drag/drop’ing the left tree nodes into fields, as drag/drop cannot be done across frames due to browser security restrictions.
4. There is also an alternative already present - Quick Update/Create. It loads a window, allowing you to edit or create any Resource or Element type without reloading the page.

If you have a better solution besides going back to frames (which MODx Revolution *will not* be doing), please let us know, we’d be open to it.

Why isn’t the tree loaded to a certain limit / depth to start with? I’m sure modern browsers can handle quite a large JSON file in memory.

Does ModX use nested set on the DB to make fetching the tree straightforward?

DM

Quote from: DangerMouse1981 at Dec 13, 2010, 06:32 PM

Does ModX use nested set on the DB to make fetching the tree straightforward?

No, but we will be adopting closure tables (not nested sets, but similar and more elegant IMO) in an upcoming release so you can query an entire tree with a single query, and so we can drop the dependence on loading the tree in the context caches.

Here’s my proposal:

- document tree should get documents 2 levels deep for 2 reasons
1. when i click the plus sign, the new pages are shown immediately (then adds it’s children to the tree in the background)
2. if the folder has no children, the plus sign is not even there
- This would make the manager much faster. At the least seem faster.

Quote from: siteleas at Dec 11, 2010, 10:39 PM

After searching the bugs website, I believe that there is a bugfix request that corresponds to what I have described above it is located here - http://bugs.modx.com/issues/2510

I put my vote for upping the priority of this bug fix

So do I.

I have discussed this issue almost two years ago when the first beta 2.0.0-beta-1 appeared. (http://modxcms.com/forums/index.php/topic,36366.msg220890.html#msg220890). While some improvements have been made and don’t get me wrong, Revolution is a terrific system in general, this tree refreshing thing still bugs me and I am sure others too. I even would accept going back to a frame and loosing the drag and drop for the sake of removing the tree refresh side-effect.

Revolution is a terrific system in general, this tree refreshing thing still bugs me and I am sure others too. I even would accept going back to a frame and loosing the drag and drop for the sake of removing the tree refresh side-effect.

I totally agree.

I get that frames is not an option due to many complaints about Evolution using them.
But I wonder if that was the real complaint?
Was it that people "hate frames"? Or was there something else, caused by using frames, what people hated?
I can only imagine that it was the latter as the first would seem a non-reason, I'm open for other views here though.

Frames do add possibilities but they can be achieved otherwise.
The Revolution manager just doesn't achieve those possibilities and, it seems, just left out frames by public demand.

A lot of those possibilities can be achieved by using ajax, which is used in the manager here and there but obviously not to the extend of being complimentary to UX.
My vote is for upping the standards here and go for an ajax driven manager. (Or re-introduce frames and come up with something innovative to solve the drag-n-drop issue)

A couple of things that could improve the UX in the short run:

- loading the 'other' tabs in the background: When switching from elements to resources or vv after saving an element/resource it's very annoying the tree has to reload again.
- caching the tree client-sided. All modern browsers support client side dbase.
- automatically refresh the manager cache after creating (and duplicating!) an element would prevent having to manually clear site cache to see the newly created/duplicated element.

I'm especially puzzled by the amount of time needed to reload the tree, even when it's cached. (Which it is because I need to clear the cache before I can see a newly created/duplicated element)
Is there a lot of javascript going on there which could be simplified or postponed?

I really hope this will be a focus for future releases.