[patch][ccla] Proposed extension: XML parser for rendering dojo

[Rob Gagne]

The attached patch reads XML and instantiates dojo components. Element names refer to the dojo component to be created, attributes refer to properties or event handlers.

XML can be included directly within <script/> tags or externally referenced via the script tags src attribute.

Some examples:

<ui xmlns:dijit="dijit">
<dijit:form.Button label="Hello, World!"/>
</ui>

Using the namespace more:

<ui xmlns:dijit="dijit.form">
<dijit:Button label="Hello, World!"/>
</ui>

HTML can be included within the XML by specifing html as the namespace uri.

<ui xmlns:dijit="dijit" xmlns="html">
<p>HTML before</p>
<dijit:form.Button label="Hello, World!"/>
</ui>

The patch includes the code, some examples and the mail demo built through xml.

(Thank you to Alex for help and guidance with this)

[guest]

patch

[bill]

Hi. Can you add your name to the "Reporter" field and also list if you have a CLA or not?

[dylan]

Reporter is Rob Gagne of Nexaweb. CCLA on file.

[guest]

Thanks Dylan - Rob

[alex]

so in looking at this, it's not clear why everything is being done under a "dojoe" namespace. This set of patches probably needs to land in a dojox namespace for now.

Any chance we can get the patch updated for that? Perhaps under dojo.xml?

[bill]

BTW I looked this over a bit. Not sure why there is a HashTable? class in your patch but the implementation worries me given that two equal elements can get different hash keys:

if (!x._hashKey){ 
 	x._hashKey = dojoe.collections.Hashtable._uniqueKey++; 
} 

which means that in the general case it's impossible to check if a given key is in the hash. (HashTable? also doesn't handle hash collisions.)

IIRC We had collection classes in Dojo 0.4 that worked well; if you really need a collection class, might just want to just port them over if they aren't there already.

[guest]

(James Margaris here. I wrote the code)

1. We can change to dojox and resubmit. Why was it dojoe instead? Odd historical reasons.

2. Hashtable does not need to be included at all, it has nothing to do with the parser. Will remove from resubmit. As far as why it is written the way it is, perhaps Hashtable is not the best name, it maps unique object keys to values. Dictionary in earlier dojo versions appears to use the toString() method of objects to map keys to values, which means unique objects with the same toString() overwrite each other.

Two equal elements (however you define equality, which tends to be poor for things other than basic types) can get different hash keys but unique objects can not. It's designed to use arbitrary objects as keys.

It's not really a hashtable I suppose in that there isn't a hash function and the backing store isn't a numerically indexed array. It's a map that maps unique objects to values without relying on toString().

But anyway it was included by accident and will be removed.

If there is a dojo collection class that implements this functionality I would be happy to port it over. I don't think there is one, but I could be wrong about how dictionary operates.

[guest]

update to original patch to move code to dojox/xml

[guest]

(Rob Gagne reporting, code provided by James Margaris; CLA has been submitted)

Added new patch (didn't replace original since the name is obsolete). Patch moves the code from dojoe to dojox/xml

[alex]

this is much cleaner. thank you.

[alex]

(In [14044]) merging Nexaweb's awesome XML parser for Dojo markup. Thanks to James Margaris, Bob Buffone, Rob Gange, Coach Wei and everyone else who helped make this happen. Fixes #5766 !strict