OJ is packaged for Node and Bower. Other options abound.
bower install --save ojs
- From NPM last stable
npm install --save ojs
- Clone from Git
git clone firstname.lastname@example.org:somecallmechief/oj.git
OJ is written in CoffeeScript. The distribution folder has the complete CS and JS for the project.
gulp compile task.
Once compiled, feel free to use OJ in either flavor.
While OJ probably doesn't have a lot of utility in the context of Node, I have made an effort to keep it Node-compatible--although there is absolutely no testing to this effect.
At its heart, OJ provides a simple API to build out the DOM:
div = OJbodymake 'div'text: "Aloha! Ahoy! Hola! Prevet!"cell11 = divmake 'table'cell 11text: 'Ahoy, column 1, row 1!'cell 21text: 'Aloha, column 1, row 2!'span = cell11make 'span'text: 'Aloha! Ahoy! Hola! Prevet!'
Nearly all standard nodes are accessible via chaining, starting with the body element. Every OJ node is chainable against the entire set of compatible child nodes. For example:
div = OJbodymake 'div'select = divmake 'select'make 'button' #not terribly rational, but valid semanticmake 'option' #more reasonable chained methodfieldSet = divmake 'fieldset'make 'legend'ol = divmake 'ol'make 'span' #not a great idea, but entirely possiblemake 'li' #preferable child nodemake 'div' #another valid child of limake 'ul' #valid child of divmake 'p' #suboptimal but validmake 'li' #valid child of li
In most cases, the
make method is your start and end point for chaining node creation. In a few cases, specific classes such as
table provide an additional convenience
method or two to make chaining simpler:
table = OJbodymake 'table' #returns an instance of tabletablecell 11text: 'Ahoy, column 1, row 1!' #the table.cell method provides a simple abstraction over table.make 'tr' and table.make 'td'tablemake 'tr' #Still valid, creates a new rowmake 'td' #Still valid, creates a new cell
The element table class provides a unique
cell method which takes in the ordinal position of the cell (row, column) and guarantees that the cell you want is in the correct location.
Further, it guarantees that the table is fully populated.
table = OJbodymake 'table' #returns an instance of tabletablecell 147text: 'Ahoy, column 7, row 14!' #cell() guarantees that rows 1-13 are created and that each row has at least 7 columns (filled with non-breaking whitespace if absent)tablecell 1412text: 'Ahoy, column 12, row 14' #cell() now guarantees that all existing rows also have 14 columns (filled with non-breaking whitespace if absent)
Likewise, the component grid class provides a unique
tile method which accomplishes the same effect for Bootstrap grids as
table.cell does for tables.
grid = OJbodymake 'grid' #returns an instance of gridgridtile 21widths: xs: 12sm: 6md: 4 #Guarantees that at least 2 Bootstrap rows exist, each with 1 column
This simple semantic makes it possible to build more complex web components, which are encapsulated as OJ classes.
divmake 'grid' #creates a Bootstrap gridtile 11 #creates row 1, column 1make 'grid' #creates a nested grid on previous tiletile 11 #creates nested row, nested column
Components are currently a work in progress, but several functional components include jQuery Sparkline, jQuery Flotchart, and Bootstrap grids.
In order for OJ to scale, it has to be fast. By far, the fastest way to insert nodes into the DOM is by calling
someElement.appendChild. Unfortunately, this is a tedious process to do manually. Rather than revert to anti-patterns like setting innerHTML, OJ leverages the speed of ThinDOM for light, fast, semantically accurate DOM insertion. This does come at a slight cost, but ThinDOM outperforms jQuery insertions by at least an order of magnitude--so it's a logical choice for the core of OJ's DOM manipulation.
While ThinDOM may be the fastest choice for getting your nodes into the DOM, it doesn't offer the cross-browser support and flexibility of jQuery's API--so for everything else you need to do to your nodes, OJ wraps around jQuery to provide access to all of the
on that you might need.
By default, OJ does not add element IDs to any of the nodes it creates. This is configurable. If desired, enable element ID creation by setting:
If enabled, OJ will generate unique element IDs for every node created. Any element ID is accessible via the
divId = divgetId
You are always free to specify your own IDs on node creation (whether or not automatic ID generation is enabled).
div = OJbodymake 'div'props: id: 'myHolaDiv'
Regardless, OJ is not optimized for fetching nodes from the DOM, rather it encourages you to reference nodes in memory as opposed to relying on "truth in DOM". For example, while you might write something like the following in jQuery:
jQuery '#myHolaDiv'append '<div id="leavingDiv">Leaving...</div>'jQuery '#myHolaDiv'append '<div>Leaving......</div>'jQuery '#myHolaDiv'append '<div id="goneDiv">Gone</div>'
And at some point later fetch the node from the DOM:
leaving = jQuery '#leavingDiv'hide;
In OJ, this is generally discouraged. Node lookups by ID are possible (e.g.
OJ.nodes.get('myHolaDiv)), but it is usually better to consolidate behavior using a reference to the object and encapsulate the logic into components.
myHolaDiv = OJbodymake 'div'leavingDiv = myHolaDivmake 'div'text: 'Leaving...'events:: ->leavingDivhidegoneDivshowgoneDiv = myHolaDivmake 'div'text: 'Gone'events:: ->goneDivhidehide
One of OJ's implicit goals is to enable a style of development free from worrying about the minutia of the DOM in order to focus more on the UI/UX you want to deliver.
- Basic HTML and CSS are fully encapsulated in strongly validated OJ classes.
- Complex forms, layouts and composites are abstracted into thin OJ classes which are extensible with mixins.
- Layouts are configurable simply by clicking and dragging the form. Validation and data binding come for free.
The Reality: Some of the most complex work has already been done. The SQL Builder demo is complete, minus actual AJAX requests. A fully fledged wrapper around IndexedDb is in place. Objects are queryable using SQL-like semantics. Raw DOM nodes are wrapped and ready. Much has been done, but much more still remains to do.
### TODO Priority 1 v0.2.0 Complete The core factory class is in place, but only SPAN and DIV have been implemented. TABLE is next, followed by INPUT (which will immediately spawn a factory subclass to handle input type: radio, checkbox, etc). SELECT (with child class OPTION) will be followed by the rest of the classic DOM Nodes.
As of v0.2.0, the entire library has been refactored to CoffeeScript. Anything non-essential to the DOM framework has been archived (the source is still included in the project under /src/archive). All standard nodes are supported: div, span, input, table, fieldset, p, b, br, ol, ul, li, select, option and more. Unit tests are in place and expanding to prove out all of the new nodes.
### TODO Priority 2 v0.3.0 Complete A secondary factory will need to implement components. There's still some implementation specing to do on how to distinguish between abstract components (e.g. an array of checkboxes) vs. concrete controls (e.g. an Address composite).
As of v0.3.0, all literal nodes (e.g. span, div, etc) are encapsulated in element classes. All controls (simple combinations of literals) are contained in control classes. Components (OJ's version of web components) are contained in component classes. An additional input collection exists to handle all the possible permutations of the literal input class.
A FORM factory is on the table, so to speak. Additional specification work is needed to define a data structure which can be implicitly cast into an OJ form, generating an ordered layout of controls and to facilitate real time data.
Feel like contributing? Wondering what in the sam hill I'm thinking? Challenge me to a duel; fork me; contact me; ignore me. Collaborate in real time [in my IDE of choice] (https://c9.io/somecallmechief/oj).
Everything I write is always Public Domain. Please take generously.