The jQote2 API Reference provides plenty of useful examples which are sure to help users get up and running quickly. I found it a bit unclear, though, as to how templates could be loaded externally as, in the reference examples, templates are defined within the containing page. For the sake of simplicity this approach certainly makes sense in the context of examples. However, in practice, templates would ideally be loaded externally.
While jQote2 provides a perfect API for templating, it does not provide a method specifically for loading external templates; this is likely due to the fact that loading external templates could easily be accomplished natively in jQuery. However, since this is a rather common development use case, having such a facility available would be quite useful.
After reviewing the comments I came across a nice example from aefxx (the author of jQote2) which demonstrated a typical approach to loading external templates which was simular to what I had been implementing myself.
And so, I wrote a simple jQuery Plug-in which provides a tested, reusable solution for loading external templates. After having leveraged the Plugin on quite a few different projects, I decided to open source it as others may find it useful as well.
Function Overwriting (also known as “Self-Defining Functions” or “Lazy Defining Functions”) provides a pattern which, as stated above, allows for overwriting a function’s definition at runtime. This can be accomplished from outside of the function, but also from within the function’s implementation itself.
A possible candidate use-case for Function Overwriting is Feature Detection as, detecting for specific feature support in the Browser typically only needs to be tested once, at which point subsequent tests are unnecessary.
Below is a basic example of implementing Function Overwritting in the context of an abstraction of the HTML5 Geolocation API.
// Initial "getLocation" implementation. Since we only need to test
// for Geolocation support once, we perform the initial test and then
// overwrite the "getLocation" implementation based on the results of
// the test.
// Geolocation is supported, so we overwrite the implementation
// to simply invoke "geolocation.getCurrentPosition" as there
// is no need to perform the test again.
// Geolocation is not supported, so we overwrite the
// implementation to simply return false (a real
// implementation might provide a polyfill here...).
As you can see, Function Overwriting provides a convenient facility for optimizing code execution at runtime. There are many use-cases for dynamically overwriting functions and, where appropriate, they can certainly provide value in terms of performance and code maintainability.
Below you can find an example which demonstrates two basic Function Overwriting implementations. Simply load the page and add some breakpoints in Firebug to test the execution paths; both before and after overwriting each function occurs, or you can simply view the source. Example
For example, consider the follow which tests for a custom data namespace attribute in jQuery Mobile:
The above test may appear quite straightforward, yet it serves as a good example by illustrating how each test in QUnit is implemented by the QUnit test fixture. The first argument is simply a String which describes the test case. This is quite convenient in that the intent of a particular test case can be expressed more naturally in textual form as opposed to using a long, descriptive test method name. The Second argument contains the actual test implementation itself, which is defined as an anonymous function and passed as an argument to QUnit.test.
As you may have also noticed from the above example, there are some, perhaps subtle, differences between the QUnit style of testing and the traditional xUnit style. Specifically, whereas in xUnit assertions expected values are specified first and preceded by actuals, in QUnit actuals are specified first followed by expected values. This may feel a bit odd at first however, after a few tests it’s easy to get used to. Additionally, where an assertion message is specified before any arguments in xUnit, in QUnit assertion messages are specified after all arguments. With regard to test descriptions, this is a difference I prefer as, a test message is always optional so passing this value last make sense. While somewhat subtle differences, these are worth noting.
A Complete Example
As code can typically convey much more information than any lengthy article could ever hope to achieve, I have provided a simple, yet complete, example which demonstrates a basic qUnit test implementation. (run) (source).
“If everyone is moving forward together, then success takes care of itself.” – Henry Ford
The HTML5 Family of Technologies has been receiving considerable coverage lately; and, rightfully so, as, many next generation browsers – specifically those in the Mobile space based on WebKit: Android, iPhone, iPad, Blackberry etc. are now beginning to implement it’s specification, or parts thereof. On the Desktop more HTML5 support is also being seen in the latest versions of Chrome, Firefox, Safari, IE9 and Opera.
The HTML5 Family of technologies will without question play a vital role in the future of the web; and currently, in the mobile Web space, that future is now.
A Brief Overview of the HTML5 Family
For anyone who is unfamiliar with what has been termed “The HTML5 Family“, allow me to provide succinct overview of the technologies which I feel encompass what has already become a rather overloaded term. In general, on a very high level, I would summarize the HTML5 Family simply as follows:
While the above could be considered the umbrella Technologies upon which The HTML5 Family is based, there are certainly more associated technologies which themselves further augment what could be considered the HTML5 Family, some of which are (based on current specification status at the time of this writing ):
Web Storage (localStorage, sessionStorage) APIs
Web SQL Database API
Web Workers API
Web Sockets API
First, HTML5. HTML5 is the next major revision of HTML which aims to advance the open Web through web standards and semantically rich content. HTML5 defines an emphasis on semantic structure and meaning.
In general, HTML5 provides a content model which can be broadly defined into the following categories: Metadata content, Flow content, Sectioning content, Heading content, Phrasing content, Embedded content and Interactive content as well as form-associated elements etc.. HTML5 defines new tags such as canvas, audio, video, keygen, header, footer, nav, article, aside, datalist and more.
HTML5 Microdata provides a mechanism which allows machine-readable data to be embedded in HTML documents in the form of annotations, with an unambiguous parsing model. Microdata is compatible with numerous data formats such as JSON. Micro-data is intended to provide a standard to replace other similar concepts such as RDFa, from which browsers and other applications can discover relevant content based on the context of an applications markup. Such examples include markup for contact information, calendar events and more. This markup is understood by HTML5 compatible browsers which can then automatically offer to add the relevant content to the appropriate application. At an implementation level, microdata simply consists of a group of name-value pairs; with the groups being called items, and each name-value pair is a property.
The HTML5 Geolocation API is rather straightforward; it simply provides a means by which the location of a device can be determined via a native API (as opposed to say, determining the clients IP address). The Geolocation spec is currently in last call status in the W3C.
Device APIs are client-side APIs which allow for direct interaction with native device services such as a device Camera, Calendar, Contacts etc.
Web Storage API
The Web Storage API allows for the persistence of local (permanent) and session based (browser session) data on the client. The API for Web Storage is extremely simple as it is based upon simple Key / Value pairs; with which Keys are simply Strings. Each site contains its own separate storage area.
Web SQL Database
While not a part of the actual HTML5 specification, the Web SQL Database presents some extremely interesting possibilities within Web Applications. The Web SQL Database provides a set of APIs which allow for the manipulation of client-side databases using SQL. The Web SQL Database is based upon SQLite (3.1.19) thus supporting the features as specified therein.
Web Workers API
Web Workers provide a mechanism by which web content can execute scripts in background threads. Web Workers allow for a much needed multi-threaded implementation for web based applications executing in a browser. While somewhat similar, Web Workers are different from threads in that they are primarily intended for executing long running, expensive computations and algorithms so as to facilitate non-blocking UI background processes. One specific aspect of Web Workers which has considerable positive implications for the web moving forward is that they run in native threads as opposed to Green Threads; as is the case in VM architectures. This is quite significant as it essentially means Web Workers can scale vertically. Considering the inevitable proliferation of multi-core desktop and mobile devices, this is certainly something that will prove advantageous.
Web Sockets API
If you are interested in learning more about each of these technologies I recommend the following resources:
Moving forward, I plan to go into further detail for each of these associated HTML5 Family technologies, providing working examples and detailed information as to how each can be utilized to create some very unique and interesting possibilities on the Web.