insin / dombuilder Goto Github PK

• DOMBuilder Code
• DOM Mode
• HTML Mode
• Backwards-incompatible changes since 1.4

Goal for 2.1 - can we use the DOMBuilder API as the basis for an object-based templating system with template inheritance?

Scattershot thoughts and questions:

• Reuse HTML mock objects in some way or introduce a new mode with its own objects which leverage the element creation function approach?
• Strings for simple things... logic functions - can these be done non-horribly?
• Compile step which keeps track of where logic needs to happen?
• Dummy nodes identify places where logic needs to happen at render time?
• Cloning as much as possible when outputting DOM elements from templates - DocumentFragments all over your face.
• Reuse the same templates to generate DOM elements or HTML.

Since we're always working with objects when generating HTML with DOMBuilder, make some use of them.

How about providing a method on HTMLElement which finds children which have ids and event handling Function attributes and registers events on the elements with the appropriate ids?

Users could call this method after they've toString()ed and innerHTMLed to set up all the event listeners - switching from DOM to HTML mode without changing any element creation code would then be a viable option for people looking for a speedup.

We could generate dummy ids for HTMLElements which have event listening function attributes but no id attribute to make this totally automatic as far as the user is concerned.

Providing a function which takes the element to be innerHTMLed and does both steps would make it even nicer.

Due to how we set attributes, it's possible to use an "innerHTML" attribute to specify the contents of a newly-created element as an HTML String in DOM mode.

Add special casing for this in HTML mode so it can be used interchangeably.

jQuery is a bit heavy to be lugging about solely for the limited subset of its capabilities DOMBuilder needs.

Look at how it's being used and see if we could make those needs pluggable, with a basic default implementation which doesn't depend on a library, but will come with a caveat as to how comprehensively it attempts to deal with cross-browser issues.

I don't see a license in the README or package.json. Mind adding one?

Provide exports for CommonJS when available.

Grab the global object by using "this" instead of passing "window" into the initialising function.

An NBSP variable has plagued DOMBuilder since it was first used to generate tables many moons ago. There are a couple of special cases in the code involving the unicode String representation of a non-breaking space.

As DOMBuilder doesn't do any HTML parsing with innerHTML, how can we make it easier to work with entities in Strings?