Meta Refactoring - APE.dom

[GarrettS]

APE.dom is a god object that can be broken up.

Breaking up APE.dom encourages keeps the size and complexity of the core trim while allowing proliferation of more interface-objects for various contexts.

Currently, APE.dom does:

• className functions (has, add, remove, toggle, getElementsBy, findAncestorWith)
• DOM Traversal (contains, findAncestorWithAttribute, nextSiblingElement, etc)
• style reading
• constants

The problems is that as more widgets are created, more context needs are created and APE.dom grows.

TODO: Investigate breaking off smaller chunks into their own objects.

Investigate where similar interface objects exist and how they can be organized. Two examples:

APE.dom.Event

APE.EventPublisher 2)

• APE.dom.getPixelCoords
• APE.dom.getOffsetCoords

className functions - APE.className? APE.dom.className? traversal functions - APE.dom.traversal ? style functions APE.dom.style? APE.elementStyle?

The DOM constants are used throughout, where does it go? APE.dom.constants, or simply remain on a whittled APE.dom?

[GarrettS]

Rename the rollup file "dom.js" to a more descriptive name that indicates what it does.

[GarrettS]

Can current calls to getStyle allow configuration for that? And how?

IOW, APE.dom.getPixelCoords calls APE.dom.getStyle. Can that instead be configured so that APE.dom.getPixelCoords calls any getStyle function, such as jQuery.css or YAHOO.util.Dom.getStyle?