Cloudy Models

This is the first in a series of posts on some of the coding patterns that I have been using with Peso .  I use the term 'pattern' loosely, referring to common code patterns that are repeated through out the implementation of the framework. The intent of the Flexible Method Pattern is to give callers of the framework functions/methods as much flexibility as possible, minimise the amount of boiler plate code required to use the framework, and keep the code as streamlined and simple as possible.  This pattern is made up of two parts. Type Specific Handling Often we might need to have the same logical operation being performed, pretty much the same way, for two or more different types corresponding to the same logical input. For example, a common operation is to retrieve an element given an ElementID or an ElementGUID.  There are two different methods on the Repository object to do this.  In the framework we can do a bit better than this.  We can write a method that takes a

An often misunderstood topic in JavaScript is the use of global objects.  This article will seek to make some clarifications on this topic, show how aspects of this issue applies within EA JavaScript scripting, and describe one of the building blocks on which the Peso framework is built on. In Javascript there is an implicit object hierarchy where every object is related to another object through a parent relationship.  The standard way of referring to the parent (or enclosing) object is through the this reserved word.  At the top of the object hierarchy the root object can be found. Depending on the JavaScript environment, there may be well known names available which refer to this root object.  For web browsers you can often rely on window , self or frames , and on Node.js you can refer to global .  However, in EA, there is no well known name for the root object. At this point, you might well ask Ok, but how is this significant? For most purposes in EA knowing the root o