Splitting up Uize.Node

[BenAtZazzle]

Not sure if this is the best place to talk about this, or if a .todo file would be better, but we've been discussing splitting up Uize.Node into multiple files in order to reduce the amount of code Uize.Widget needs. Uize.Node would become an aggregator method in the same way Uize.String has become one for backwards compatibility.

Here's my proposal (names are still TBD):

Uize.Dom - new namespace (like Uize.Str)

Uize.Dom.Common - essentially the commonly-used methods (majority of which Uize.Widget needs)

methods:

• display
• doForAll
• find
• getById
• getInnerHtml (doesn't exist, but seems like it should for parity)
• getStyle
• getValue
• injectHtml
• isNode
• isOnNodeTree (used by find and other methods)
• joinIdPrefixAndNodeId
• remove
• setClipRect (there is a setNodeClipRect method which is only used by 3 widgets, so not sure of its worth)
• setInnerHtml
• setOpacity
• setProperties
• setStyle
• setValue
• show
• unwire
• unwireEventsByOwnerId (used by unwire)
• wire

static properties:

• ieMajorVersion
• isIe
• isMozilla
• isSafari

methods that aren't used by Uize.Widget but don't have a home:

• getDocumentScrollElement
• getText
• showClickable

Uize.Dom.Pos - essentially the positioning stuff

• centerInWindow
• getCoords
• getDimensions
• getEventAbsPos
• setAbsPos
• setAbsPosAdjacentTo
• setCoords

Added to Uize.Math.LogicalPos

• doRectanglesOverlap

Thoughts?

[BenAtZazzle]

To continue the discussion, here's information on the Uize.Node methods that the modules in the "namespace" use. The thinking is two-fold.

1. These Uize.Node.* modules should probably live in the Uize.Dom namespace so that they no longer need to pull in everything that the Uize.Node aggregator module will be pulling in.
2. Since the modules don't use everything that even Uize.Widget uses, we might want to break into Uize.Dom.Common even smaller chunks

Uize.Node.Classes uses:

• Uize.Node.isNode
• Uize.Node.getById
• Uize.Node.doForAll

Uize.Node.CssModule uses:
[no Uize.Node methods!]

Uize.Node.Event uses:
[no Uize.Node methods!]

Uize.Node.Form uses:

• Uize.Node.doForAll
• Uize.Node.find
• Uize.Node.getValue
• Uize.Node.setProperties

Uize.Node.Tree uses:

• Uize.Node.getById
• Uize.Node.getText

Uize.Node.Utiluses:

• Uize.Node.getById
• Uize.Node.getStyle
• Uize.Node.isIe

Uize.Node.VirtualEvent uses:

• Uize.Node.wire

Uize.Node.VirtualEvent.Edge uses:

• Uize.Node.wire
• Uize.Node.getEventAbsPos
• Uize.Node.getCoords
• Uize.Node.getStyle

[UIZE]

Just for the record, this is a proposal that "we" discussed several times before. And, I agree, this is a good direction to go in. I have acted on our proposal and created the first Uize.Dom.Basics and Uize.Dom.Pos modules under the new Uize.Dom namespace.

Thanks for looking at the other Uize.Node.* modules and how they utilize features from Uize.Node. I will migrate more of those over into the Uize.Dom namespace in time.

Generally, an issue like this is a little bit big, and it would be better to break something like this up into smaller issues so that I don't end up with some overwhelming (and depressing) neverending issue that takes forever to close.