Opened 15 years ago

Closed 15 years ago

#2491 closed enhancement (wontfix)

Disabling the parsing of a nodes childNodes

Reported by: [email protected] Owned by: dylan
Priority: high Milestone:
Component: Parser Version: 0.4.2
Keywords: Parser Cc:
Blocked By: Blocking:


It is desirable to be able to specify on a particular node that it should not be parsed by Dojo. My current set up is that I set the djConfig.searchIds array to be the ids of all the widgets on the page.

However, Dojo still parses inside these widgets, and there seems to

be no way to specify which nodes should and should not be parsed. This does not scale well, for example with very large unordered lists.

While I have set "isContainer : false" on the particular widget being applied to the <ul> element, this does not effect the parsing of the page. What would be useful would be to set isContainer="false" on my node in markup , and the dojo.xml.Parse.parseElement would check for this before parsing all the child elements.

I realise that it is possible to instantiate widgets programmatically, but we are trying to keep as little javascript as possible on the HTML page.


Attachments (1)

Parser.patch (504 bytes) - added by [email protected] 15 years ago.
Patch to implement the functionality described in the ticket

Download all attachments as: .zip

Change History (4)

Changed 15 years ago by [email protected]

Attachment: Parser.patch added

Patch to implement the functionality described in the ticket

comment:1 Changed 15 years ago by alex

Milestone: 0.4.2

comment:2 Changed 15 years ago by [email protected]

I am also experiencing this same issue using the Split Container Widget, with other Widgets within the container. The Container has a fairly large un-ordered list, with a few dojo Widgets and is thus extremely slow. Thanks, Todd

comment:3 Changed 15 years ago by bill

Resolution: wontfix
Status: newclosed

Given the way the parser has been rewritten for 0.9 (using dojo.query()), it's not really possible to do this. But hopefully the new code is fast enough that this is no longer an issue.

Note: See TracTickets for help on using tickets.