Meta Refactoring - APE.dom #11

GarrettS opened this Issue Aug 23, 2010 · 2 comments


None yet
1 participant

GarrettS commented Aug 23, 2010

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.elementStyle?

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

  • Owner

    GarrettS commented Aug 24, 2010

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


    GarrettS commented Aug 24, 2010

    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?

    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment