Random Screenshot: My “Composable” Display Builder for JavaScript
Today marks my ‘official’ understanding of how to deliver a REST-based user interface. Please hold any supportive comments of applause. This is important to me because now I am able to speak at length about building these things. This means that I am able to profess about these things. This allows me to consider myself a “professional” in this matter, according to my personal standard of professionalism. So there.
What is strange (to me) about this announcement is that I have been using JavaScript, CSS and XHTML in the REST context for years with incredible success. But only today do I consider myself able to actually talk about what I have been doing (or trying to do what I now do better). Not being able to talk about something makes me literally dumb. So today I am announcing not that I am smart but only my ability to speak with regard to this area of concern. So blah.
The magnitude of this announcement is of the same size as what produced documents like “Songhay.NET: An Overview of the Songhay Namespace.” This means that my commitment to me demands that a JavaScript document will be written (‘soon’). In the mean time, the picture at left shows my display builder pattern. I am not saying I invented this pattern I am just claiming it as mine just in case I find out a few minutes from now that this pattern is flawed and ridiculous. As of now, it is not.
The assumption here is that I am using some of the basic principles of functional programming by ‘stacking’ a bunch of independent display building functions on ‘top’ of each other. So a display builder like displayBuilder.forKbNote() is completely independent of any other display builder. All it does is query a fragment of XHTML for one or more elements each with a particular id (or CSS class). When the element(s) is found, then the display builder does the work of progressive enhancement, when the query fails the function does no work.
And I used the word “query” in the previous paragraph to grant myself permission to record my opinion of jQuery. I do not see a need for jQuery right now because my conventional framing confines my designs to only one DOM query—and this kind of query is handled by YAHOO.util.Dom.get(). Note that in the previous paragraph I used the phrase ‘fragment of XHTML’—this implies that my AJAX designs put the X back into AJAX. My brief investigations of jQuery suggest to me that it is needed to build DOM elements with the DOM and JSON data. This means that jQuery people are wont to send and receive JSON messages before they “resort” to XML. For me, JSON is my last resort (and, Doug, I really do use JSON).
The increasing requirement of JSON and DOM manipulation means (to me) that the JavaScript-based client is trying to reduce local-remote chatter—and the increase of local remote-chatter is (to me) a metric of increasing complexity. Since I am not on the Yahoo! Mail team or the Gmail team, increasing complexity means that I better “rethink” the foundational reasons why I am building a JavaScript-based REST client. My “rethinking” may lead me to green-field reasons why I would build in AIR, Flex or Silverlight (or even Google Gears).
This announcement comes about six months after my last ‘random screenshot’ post, “Random Screenshot: A Solidified ASP.NET Server Design.” That both of these posts are introduced with a random screenshot is another one of those strange coincidences that makes writing journals with information machines interesting.