let the markup explicitly specify terminal dojoType nodes

[lipik]

Hi, I have a suggestion to speed up dojo.parser, without extensive changes. The idea is simple: like dojoType, introduce another attribute, dojoTerminal, which can be true or false. If this is set to true, it is hint to the parser that there are no elements with a dojoType attribute under this branch, so the parser (or the initial query) can terminate the traversal early. I believe this feature, judiciously utilized, will significantly speed up parsing on complicated pages and would be fully backward compatible.

The implementation of this would be simple - probably just a matter of rewriting a query string.

[bill]

Hi Lipik,

Yes I've thought about stuff like this for 2.0, plus doing deferred parsing, ex: waiting until a tab pane is shown before parsing it.

Something like dojoTerminal is hard w/the current parser architecture because it finds nodes with dojo.query(), which just returns a flat list of nodes containing dojoType, with no regard to hierarchy.... so would probably have to give up on using dojo.query().

[lipik]

Well, I am assuming that the selector engine (either browser native, or ACME) would implicitly optimize its parse traversal with a query-string like so:

"*[dojoType] *:not([dojoTerminal])"

as against

"*[dojoType]"

I will try to run some tests and attach them here.

Another idea might be to detect the type of the second argument to dojo.parser.parse, and if it happens to be an array, assume that it is the complete list of nodes that the user wants to be parsed, and there is no need for a DOM traversal.

[bill]

For 1.5 (or was it 1.6?) I added a _stopParser flag to widgets; if it's there then the parser doesn't parse descendants of that widget. Not quite the same though.

Parser is no longer using dojo.query(), it's running top-down, which would make this enhancement fairly simple.

[ben hockey]

bill, i think _stopParser might be enough to close this ticket. is there some other reason to keep it open?

[bill]

Well, _stopParser is on the widget prototype whereas this ticket is about a flag in the markup (ie, index.html file) itself.

I guess I was leaving the ticket open to see how things go with the async-parser changes. If we keep the top-down parser then I'll implement this, otherwise close it as wontfix.

[Kitson Kelly]

I personally don't like the terminate parser... the idea of having a customisable CSS selector to select the nodes (which I am proposing in the 2.0 parser) would allow this to work in this scenario (plus a lot of others).

I suggest we close this.

[bill]

Actually I needed to implement this to get server side instantiation working correctly. It's in [30789]. It works by putting the stopParser property (not attribute) on any node.