Jessie has a flat API. It is simply a collection of functions where jessie is the default namespace* to attach those functions to so that they are not on the global object.
jessie.attachListener
jessie.getDescendantsByClassName
jessie.parseJson
jessie.forEach
*You can replace jessie with any name you want giving you that extra personal touch for your custom build.
Additionally you can use the builder to choose which functions you want in your custom build for your library.
Renditions
Each function has one or more renditions. Each rendition is based on feature detection, feature testing and the context of your application i.e. what type of application are you building and what browsers are you supporting. You need to think about which rendition suits your context best.
Let's take a look at an example function with particular renditions:
jessie.attachListener is a function to add event listeners to dom nodes. It (currently) has three renditions:
W3C compliant el.addEventListener
Microsofts implementation el.attachEvent
A combination of #1 and #2
If you're building a mobile only site or a site that only has to work in Chrome or Safari etc then rendition #1 will be perfect.
If you're building an intranet site that only has to work in IE7 then you can use rendition #2.
If you're building a site for many browsers then you will choose rendition #3 which is a combination of rendition #1 and rendition #2.
Dynamic API
Most of the jessie functions are dynamic. This means the calling application should check the functions existence before using them allowing the application to degrade (as if JavaScript was turned off). Let's take an example:
if (jessie.attachListener && jessie.addClass) {
// write an application that relies on (and uses) attachListener and addClass
}
A positive side effect of this design is that you have two choices of what to do when a particular function is not supported in a particular browser:
Degrade gracefully
Simply create another rendition that allows that function to work in another set of browsers.
There will be no change to the application code meaning Jessie can grow or shrink as your project requirements change.
Only the highest-level functions should be detected. Failure to detect API functions will result in applications that are unpredictable outside of supporting environments. This may be acceptable in some contexts (e.g. PhoneGap apps), in which case the detection can be skipped.
Peter Michaux has an excellent article based on this concept.
General information
Jessie has a flat API. It is simply a collection of functions where jessie is the default namespace* to attach those functions to so that they are not on the global object.
jessie.attachListener jessie.getDescendantsByClassName jessie.parseJson jessie.forEach *You can replace jessie with any name you want giving you that extra personal touch for your custom build.
Additionally you can use the builder to choose which functions you want in your custom build for your library.
Renditions
Each function has one or more renditions. Each rendition is based on feature detection, feature testing and the context of your application i.e. what type of application are you building and what browsers are you supporting. You need to think about which rendition suits your context best.
Let's take a look at an example function with particular renditions:
jessie.attachListener is a function to add event listeners to dom nodes. It (currently) has three renditions:
W3C compliant el.addEventListener Microsofts implementation el.attachEvent A combination of #1 and #2 If you're building a mobile only site or a site that only has to work in Chrome or Safari etc then rendition #1 will be perfect.
If you're building an intranet site that only has to work in IE7 then you can use rendition #2.
If you're building a site for many browsers then you will choose rendition #3 which is a combination of rendition #1 and rendition #2.
Dynamic API
Most of the jessie functions are dynamic. This means the calling application should check the functions existence before using them allowing the application to degrade (as if JavaScript was turned off). Let's take an example:
if (jessie.attachListener && jessie.addClass) { // write an application that relies on (and uses) attachListener and addClass } A positive side effect of this design is that you have two choices of what to do when a particular function is not supported in a particular browser:
Degrade gracefully Simply create another rendition that allows that function to work in another set of browsers. There will be no change to the application code meaning Jessie can grow or shrink as your project requirements change.
Only the highest-level functions should be detected. Failure to detect API functions will result in applications that are unpredictable outside of supporting environments. This may be acceptable in some contexts (e.g. PhoneGap apps), in which case the detection can be skipped.
Peter Michaux has an excellent article based on this concept.