Cloudy Models

Similarly to the Return Wrapped Object Pattern , this one involves reading the EA value for an enumerated attribute value and returning a corresponding object. get objectType() { return ObjectType.fromCode( this.wrappedObject.ObjectType ); } The code stored by the native attribute ObjectType is decoded by the ObjectType enumerated type, and the enumerated value object is returned.

Any time we have an EA object return another object we need to catch the operation and return an equivalent wrapper for the object returned.  To handle these cases we use the Return Wrapped Object Pattern , which is illustrated by the following example code. get element() { return this.elementFactory.newElementWrapper( this.wrappedObject.Element ); } That is a getter is defined for the wrapper class which calls a factory method to return the wrapped equivalent. A variation on the above is when an EA object refers to the ID or the GUID of a related object.  For these cases a variation on the previous pattern can be used to achieve the same result. get parent() { return this.repository.getElement( this.wrappedObject.ParentID ); } That is, a getter is defined for the wrapper class which calls the repository object (actually the RepositoryWrapper object) to retrieve the relevant ElementWrapper corresponding to the ID in question. ...

This should be a quick blog entry to document some of the conventions I have used in the  framework  to get a handle on Javascript module management for model addins. Element Naming Convention As discussed  here , all the element based creator functions for module addins are available at the global scope, so every class knows about every other class, hence polluting the global namespace.  Therefore the naming of classes needs to be carefully considered to avoid clashes. The scheme I have used is to build the namespace for each module into the name of the element.  For example, the module with namespace "ser.ea.element" is called "ser_ea_element".  That is, the dots (.) have been replaced by dashes (_). I'm not entirely happy with this workaround.  I've got a few ideas to have something different but they will probably require further customisation within EA, and a fair amount of experimentation.  For the moment, this naming workaround will ...

As discussed in  Module Management - Analysis , EA does not provide support for the ubiquitous Module Pattern .  This becomes an issue with an increase in complexity of model addins.  In order to a) Minimise the management of dependencies, and b) Cater for the use of 3rd party modules, The  framework  provides an analogous pattern, which I'm calling the getModule() pattern, because I lack imagination. The premise is straight forward.  Rather than having an anonymous self executing function returning a module object, we instead have module class elements which have a method called "getModule()"  and this returns a module object when the method is called. The getModule() method would be declared (via the EA interface) on a class element, and then we would place all of the module's code in the body of the getModule() method/operation.  The method would return a module object to the caller. The sample contents of a typical getModule() operation ...

I was going to do a single post on how JavaScript module management is done on Peso , however it ended up being a rather long post.  So instead I thought it would be more manageable to break it down into a number of smaller posts. This first post covers, in a sense, the background to how I came to make the decision to develop within the framework module management capabilities.  This introductory blog post is still rather large, so I have tried to clarify my thoughts under the following headings. Requirements JavaScript Quick Tour EA Capabilities and Constraints Some Conclusions Note, that what I'll be detailing here is my approach, based on the information and understanding available to me at this point in time.  Others may have different ways to solve these issues.  If in future I find better ways, then I will change what I've done in accordance with any new information.  If I am horribly wrong, then at least, at a minimum, this will serve as an examp...

The following article provides an overview of the new Javascript capabilities in meta programming .  Similarly to the GlobalThis article , this is unlikely to be of interest unless you find yourself building some sort of a framework or something a bit more exotic.  The article does not provide much of additional information on Peso, however it sets the scene for the next few articles which rely on these new capabilities. The  Wikipedia  entry for Meta programming is kinda in the ball park, however if you're familiar with the terms  Meta Object Protocol (MOP) , or  Reflection  in regards to other languages, then this is probably closer to the mark with regards to the Javascript capabilities. Javascript has always had quite a few features that made the language dynamic in that attributes could be added to an object at any time.  Methods of an object were the same as normal attributes except they were of type "Function" and they could be invoked...

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 ...

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 ...

One of the reasons I became a fan of Enterprise Architect was that it was extensible via its scripting functionality. I went through a period where I did a lot of scripting in Javascript for EA, however eventually I became disillusioned as I started hitting the limits of the functionality. The two primary issues were The Javascript engine used within EA was quite old (pre version 15) and hence the latest language features in Javascript were not available within EA. The more interesting extension points within EA were only available through the Addin protocols/interface, and these were not available in the scripting environment. I have at various times, and in different contexts, have developed scripting frameworks for EA, a published example is available from Github ( here) .  However, because of the two issues given above I  had pretty much given up on Javascript as an extension option for EA and instead had been spending time using C# to muck around with an AWS addin th...