Today, I'm going to talk about the Unit of Work pattern and how it can be useful in a presentation tier. For those of you familiar with this pattern, it was intended for aggregating an object and later committing to a database. The book definition for Unit of Work is:
I discovered that at least part of this - Maintains a list ... and coordinates the writing out of changes - proved useful in creating cohesive, reusable web components. Why? Because in today's rich web experience, those components are comprised of both HTML and JavaScript. HTML has a one-to-one correspondence between tag and element on the web page. However, with JavaScript we can ascribe behavior to multiple elements at once; it can be one-to-many. HTML is the templating language and so where it appears in the source matters. JavaScript augments that markup and can be done before or after the page is rendered. Let's walk through an example using Unit of Work for a "Unit on the Screen".
We're all in agreement that attaching JavaScript behavior after your DOM like this is good. It has Separation of Concerns. Putting it at the bottom allows the page to load faster.
But what if we want to make some reusable components for our application? Afterall, that is the principle of DRY, Don't Repeat Yourself.
This is bad. The caller of ui:text has no way of knowing the class of the resulting element to setup the CSS Selector. Also, the caller can forget to attach the behavior and the idea of reusable "ui:text" is not preserved within the application as being consistent. There is no cohesion.
Solution: BottomJS. It implements the Unit of Work pattern to have the reusable component render HTML and also add the JavaScript to be attached later at the bottom of the page.
Generates the following. The reason is BottomJS builds an in-memory set of the JavaScripts to be added at the last step so redundant calls are ignored.
Read More »
Maintains a list of objects affected by a business transaction and coordinates the writing out of changes...
I discovered that at least part of this - Maintains a list ... and coordinates the writing out of changes - proved useful in creating cohesive, reusable web components. Why? Because in today's rich web experience, those components are comprised of both HTML and JavaScript. HTML has a one-to-one correspondence between tag and element on the web page. However, with JavaScript we can ascribe behavior to multiple elements at once; it can be one-to-many. HTML is the templating language and so where it appears in the source matters. JavaScript augments that markup and can be done before or after the page is rendered. Let's walk through an example using Unit of Work for a "Unit on the Screen".
We're all in agreement that attaching JavaScript behavior after your DOM like this is good. It has Separation of Concerns. Putting it at the bottom allows the page to load faster.
// markup
<html>
<body>
<form>
<input id="firstName" name="firstName" type="text" class="textbox">
<input id="middleName" name="middleName" type="text" class="textbox">
<input id="lastName" name="lastName" type="text" class="textbox">
<input id="birthDate" name="birthDate" type="text" class="datebox">
</form>
</body>
<script src="behavior.js"></script>
</html>
// behavior.js
$(document).ready(function() {
$(".textbox").change(function() {
Utils.uppercase($(this));
});
$("#birthDate").datepicker();
});
But what if we want to make some reusable components for our application? Afterall, that is the principle of DRY, Don't Repeat Yourself.
// ui:text
<input id="{{id}}" name="{{id}}" type="text" class="textbox">
// ui:date
<input id="{{id}}" name="{{id}}" type="text" class="datebox">
// markup
<html>
<body>
<form>
<ui:text id="firstName"/>
<ui:text id="middleName"/>
<ui:text id="lastName"/>
<ui:date id="birthDate"/>
</form>
</body>
<script src="behavior.js"></script>
</html>
// behavior.js
$(document).ready(function() {
$(".textbox").change(function() {
Utils.uppercase($(this));
});
$("#birthDate").datepicker();
});
This is bad. The caller of ui:text has no way of knowing the class of the resulting element to setup the CSS Selector. Also, the caller can forget to attach the behavior and the idea of reusable "ui:text" is not preserved within the application as being consistent. There is no cohesion.
Solution: BottomJS. It implements the Unit of Work pattern to have the reusable component render HTML and also add the JavaScript to be attached later at the bottom of the page.
// ui:text
<input id="{{id}}" name="{{id}}" type="text" class="textbox">
<ui:bottomJs>
$(".textbox").change(function() {
Utils.uppercase($(this));
});
</ui:bottomJs>
// ui:date
<input id="{{id}}" name="{{id}}" type="text" class="datebox">
<ui:bottomJs>
$("{{id}}").datepicker();
</ui:bottomJs>
// markup
<html>
<body>
<form>
<ui:text id="firstName"/>
<ui:text id="middleName"/>
<ui:text id="lastName"/>
<ui:date id="birthDate"/>
</form>
</body>
<ui:bottomJs/>
</html>
Generates the following. The reason is BottomJS builds an in-memory set of the JavaScripts to be added at the last step so redundant calls are ignored.
<html>
<body>
<form>
<input id="firstName" name="firstName" type="text" class="textbox">
<input id="middleName" name="middleName" type="text" class="textbox">
<input id="lastName" name="lastName" type="text" class="textbox">
<input id="birthDate" name="birthDate" type="text" class="datebox">
</form>
</body>
<script>
$(document).ready(function() {
$(".textbox").change(function() {
Utils.uppercase($(this));
});
$("#birthDate").datepicker();
});
</script>
</html>
