TYPO3 Core

Did you have a look at the new AJAX pagetree Benjamin Mack developed?
It was announced on the core list end of december 2006, see http://lists.netfielders.de/pipermail/typo3-team-core/2006-December/006702.html

Yes, I've seen the announcement of the excellent AJAX idea.

HTML code should be cleaned anyway, regardless the method of accessing the hierarchy. It is not convenient to have over 2700 bytes of HTML code per item.

I didn't like that either. Also there is still a lot of inline event-handler ("onclick....") and also the clickmenu which is completely procedural inline-javascript and takes up about 10-15KB per complete load of the pagetree frame.

The clickmenu refactoring will be my next task.
Since we have the faboulus prototype library now we can fall back on its AJAX and DOM features and reduce code (also with putting it into an external file).

When expanding tree with 5000 pages, AJAX solution is even worst than non-AJAX.

Browser just isn't responding until it fetches the whole tree, which can take 1 minute on fast connection.

Can we do some partial expanding - sort of pagination in the tree?

interesting. Here's the thing:
Somehow AJAX (Javascript) is probably either
a) blocking the browser while fetching the huge amount of data from the server
b) or taking up all the memory when loading the huge XML in the JS object
c) or the reassigning of the drag/drop thing takes too long (it iterates through all items, but that shouldn't be a blocking thing)

My guess is that it is point b)

Can you monitor your CPU load while doing the expand?

Here's what I could do first: Getting the HTML tree code even smaller with taking out the oncontextmenu items which can be assigned dynamically.

But true, we need to figure out a long-term solution although expanding one huge tree at once does happen to like 0.001% of the users, maybe you can find a workaround in the meantime with expanding just parts of it bit by bit.

My CPU load while expanding the tree: the first 90% of the time frame CPU usage is less than 5%, and then it peaks to 45% in the last 10% of the time frame.

Is it possible to transfer the necessary stuff only, not the complete HTML? Earlier there was over 2700 bytes of HTML code per item. Can we do something about it, since this can be definitely the reason why is everything so slow:
2700*5000=13500000=13 MB

Ah, alright, thank you very much for the information. The problem is that TYPO3 takes quite long to finish the request, building the request on the server-side. Anyway, this JS-blocking is way uncool (since AJAX should be A-synchronous).

With 4.1 one tree element is around 750 Bytes. With 5000 items it is still 3.6 MB of traffic, and this will still take long with every connection.
I think I can bring it down to 500 Bytes per item but this is really the minimum. Building it together on the client side will be kind of difficult and requires a lot of changes,

One other thing is to temporarily disable the contextmenuhandlers and tell me if it takes not as long to load (in UserTSConfig options.pageTree.disableIconLinkToContextmenu = 1).

In the meanwhile I try to find out why AJAX is blocking your browser. I assume you're using Firefox!?

Yes, I'm using Firefox. I cannot properly reproduce "blocking" now. Maybe new version of Firefox fixed it?

Here is the test (fast connection) for 1700 articles:

with disableIconLinkToContextmenu: 21 sec
without disableIconLinkToContextmenu: 31 sec

Both cases are extremely slow for editors. Can we introduce sort-of-pagination, so it can load part by part, when necessary?

Benjamin, blocking occurs when using Internet Explorer, not Firefox.

It doesn't block while downloading subtree, but just before displaying it.

Blocking means: the complete IE is inaccessible during that time; switching to it using Alt+TAB doesn't display any part of IE user interface.

Hey John,
thanks for the more detailed information.
I used the "replace" when inserting the data and this is probably the bottleneck that's why IE is freezing. So right now I am looking into a faster alternative for:

$(obj.parentNode).replace(xhr.responseText);

I'll keep you posted.

Hey John.

Just a quick heads up here.

Now I found time to test a mid-huge tree (500 items). It really is slow and is blocking everything in IE. But I also found out that IE blocks in general if JS does some processing (e.g. registering the handlers), which is only noticable when having a lot of entries.

So, the main problem is the "outerHTML" parameter which is IE specific. I tried to build a workaround for this function but without success yet. I'll see what I can do.

Benjamin, I think we should focus on the speed issue, not IE blocking problem itself. If we make it faster, then blocking won't be noticeable.

E.g. we will not load all 500 items at the time, but only 50 + showing additional item at the end providing option to load the next 50 + item to load all.

Then we can make this value configurable (number of items per request = 50, or 0 to always load all items).

Is that still an issue today?
Different things have changed since you reported this issue:
- The pagetree rendering has been changed (Ext JS pagetree). I don't know, if that made the tree bigger or smaller (in MB).
- The issue is now nearly four(!) years old. Computers have become faster in that time.
- Internet Connections have become much faster, too.
So: Is that still a problem?

Hey Christopher,

I remember the issue. I think the bottleneck is the internet explorer and its javascript engine, and cannot deal with it.

But maybe we should set it to "won't fix" as there is probably no easy solution to solve this if the ExtJS pagetree is not gonna help much.

Stefan Galinski, who develops the ExtJS pagetree, just wrote me the following via private mail:

- The ExtJS pagetree basically renders much faster than the old tree (tested in Chrome).
- Since the Ext JS tree uses lazy rendering, it should also be faster with constructing bigger trees.
- Additionally for bigger trees a limit of the number of nodes to load in one step is planned to be implemented, so that loading also is fast for bigger trees. But this still has to be done.
- Since this limit has not yet been implemented, the Ext JS tree at the moment still is rather slow when you open a big tree for the first time.

Implementing this limit of nodes to load in one go should solve the issue (if it was not also solved without).

Please see the issue in the forge project for the new pagetree for more details:
http://forge.typo3.org/issues/10874

Here resolved, the issue will be fixed there.