mf Object Methods Part 2 {mf.object}

This is a series of posts that explains some of the fundamental rules for developing complex JavaScript applications and the mf framework.

In my previous post on the mf object methods I discussed several methods that act against a single object. In this next series of object methods I will begin demonstrating some of the mf object methods that deal with arrays of objects. When we look at applications within the business sphere we in most cases have to deal with large amounts of data that is displayed in grids and other standard user interface implementations. When dealing with this type of data you need to envision, in regards to a grid, what types of behaviour and functionality you need to provide to the consumer. There are some obvious features like sorting and search plus filter. As such we need to provide these types of methods as part of the object methods. In the future of mf I will be developing a store object which will make significant use of these methods. In this post I will discuss the following methods…

  • mf.object.exec
  • mf.object.normalize
  • mf.object.merge
  • mf.object.sort
  • mf.object.search
  • mf.object.difSearch

Continue reading

Advertisements

mf Object Methods Part 1 {mf.object}

This is a series of posts that explains some of the fundamental rules for developing complex JavaScript applications and the mf framework.

It has been a few weeks since I wrote a post on mf but this has most been due to the time it took to complete all of the object methods available.  Object methods along with array methods are some of the most important methods that any framework can have and as such taking some extra time is required. At present there are 28 methods written and fully tested. Given this number it would obviously be far to much for one single blog post. As a result I will be writing several blog posts each covering several methods at a time. In this post I will discuss the following methods:

  • mf.object.each
  • mf.object.deepEach
  • mf.object.clense
  • mf.object.typeMap
  • mf.object.containsKeys
  • mf.object.containsVals

Continue reading

Making a Browser Sniffer for mf

This is a series of posts that explains some of the fundamental rules for developing complex JavaScript applications and the mf framework.

One of the first key things that is required in any JavaScript framework is a browser sniffer. Browser sniffers are easy to create and as with all of the modules that will be placed into mf it uses my standard design pattern. Here is the code:

var browser = Object.freeze((function(){
     var app = new String(navigator.userAgent),
     mode = document.documentMode,
     isIE = app.match('MSIE')!==null,
     isSafari = app.match('Safari')!==null && app.match('Chrome')===null,
     isChrome = app.match('Safari')!==null && app.match('Chrome')!==null,
     isFireFox = app.match('Firefox')!==null,
     tests = {
           isSafari : isSafari,
           isChrome : isChrome,
           isFireFox : isFireFox,
           isIE : isIE,
           isIE5 : isIE && mode===5,
           isIE6 : isIE && mode===6,
           isIE7 : isIE && mode===7,
           isIE8 : isIE && mode===8,
           isIE9 : isIE && mode===9,
           isIE10 : isIE && mode===10,
           version : 0,
           isWin : navigator.platform.toLowerCase()==='win32',
           isMac : navigator.platform.toLowerCase()!=='win32',
           isSecure : (window.location.protocol).toLowerCase().substr(0,5)==='https'
     },
     Public = {};
     // get browser version
     if(isFireFox){
           tests.version = parseInt(/Firefox\/(\d+\.)/.exec(app)[1],10)
     }else if(isChrome){
           tests.version = parseInt(/Chrome\/(\d+\.)/.exec(app)[1],10)
     }else if(isSafari){
           tests.version = parseInt(/Version\/(\d+\.)/.exec(app)[1],10)
     }else if(isIE) {
           tests.version = parseInt(/MSIE (\d+\.)/.exec(app)[1],10)
     };                             
     tests.mfCompliant = (isSafari && test.version>4) || (isIE && tests.version >8 && mode>8) || (isChrome && tests.version>20) || (isFireFox && tests.version>14);
     // convert results into anonymous function calls
     for(prop in tests){
           Public[prop]=new Function('return '+tests[prop]+';')
     };
     return Public;                                    
}()));

Note that I am adding the mfCompliant property onto the tests object and setting my browser minimum requirements.  I am also not testing for Opera although that certainly could be added in very easily at any point in the future.  Finally I enumerate through the tests object and create anonymous functions within the Public object that return the values of the subsequent property in the tests object.  Note also the the public returned by the outer anonymous function is passed to the Object.freeze method in order to freeze the resulting object. This will prevent users from overriding existing methods or removing them.

In the case of IE9 it does not support the Object.freeze method.  As a result I had to place the following code above this module.

// Ensure we have freeze method on Object for IE9
if((typeof Object.freeze).toLowerCase()!=='function'){
       Object.prototype.freeze = function(o){
              return o
       }
}

Sine the freeze method returns the object being frozen this little override does the same thing in order to ensure when running the framework in IE9 it does not blow up on you.  Freezing is certainly handy on objects but does not add any direct functionality to the framework.

The mf global variable browser is then returned as belonging as a child object to the framework.  This then allows external users to make calls such as mf.browser.isIE() or mf.browser.isSecure(). Certainly over time there may be other items to add under the browser module but these are the basics.

In my next post I will be fleshing out some other core methods for Objects, Arrays along with some base prototyping of core JavaScript objects such as String and Number.

Why am I writing the mf Framework

I suppose the question of why write yet another framework should be answered to some degree. Over the many years of working with JavaScript developers from junior to senior I have noted a common theme. In almost every case the developer indicates that they know this framework or another framework yet none of them seem to understand how it is written. It is akin to knowing how to drive a car yet not understanding how it works. I think that is a dangerous mindset for both driving and writing JavaScript.

All JavaScript frameworks have common methods each with its’ own unique slant on implementation. All frameworks consist of browser sniffers, DOM normalization plus Event and Component Management along with methods to make life a little easier for the programmer. Each of these concepts offer the same or similar implementation yet there seems to be a gross lack of understanding on how they work.

So the goal of creating the mf framework is to demonstrate to JavaScript developers the basic concepts of how frameworks are put together in order to further their understanding of other frameworks. So like driving a car you should have some idea of how the engine actually works!

So, in the next several months I will be building up the framework piece by piece with one or more blog posts on each of the components that will constitute the end product.  Once I have the framework developed to a certain point I will also be placing it up on Google code for people to play with, enhance or throw mean reviews back at me.

Cheers
Keith