Builder is a framework for automating common steps performed when rendering content on your client side.
<script src="jquery.js"></script> <script src="dist/Builder.min.js"></script> <script> // Demonstration of jQuery Builder // Specify Jade as our template engine Builder.set('template engine', jade.render); // Register a few plugins Builder.addPlugin('datepicker'); Builder.addPlugin('timepicker'); // Render our view via jQuery var template = [ '#main', ' input.datepicker', ' input.timepicker' ].join('\n'), $content = Builder(template); // Content is a jQuery collection of #main $content; // [<div id="main">] // The children have also been rendered $content.find('.datepicker'); // [<input class="datepicker">] // and datepicker has already bound to the DOM and is visually represented // the same goes for timepicker </script>
From my perspective, client-side markup (HTML or otherwise), should encapsulate any and all interactive components. As a result, Builder was designed to handle anything you throw at it; from template rendering to plugin instantiation.
There are 4 steps which Builder runs through:
Builder.before(fn);- Any alterations/instrumentation to perform on the input for Builder
Builder.template(tmpl, data);- Parse template string through its engine. This would render Jade into HTML.
Builder.domify(content);- Converts HTML into HTMLElements, jQuery elements, or whatever you choose.
Builder.after(fn);- Any alterations/instrumentation to perform on the output of Builder
Builder came out of a want to DRY up client side code. I saw the pattern and repetition present that the same template engine and jQuery plugins would be called over and over in different places.
It was extremely extensible and open however it was too many steps removed from the problem. Any and every jQuery plugin would need a custom wrapper and I sincerely disliked that.
After stepping back and thinking about it long enough, I came up with Builder which slowly grew into what you see today.