Module Conventions - Part 2 - Naming Conventions

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

EA Wrapper Modules

A large part of the framework is a set of wrappers around the standard automation objects.  In the user guide the automation objects are grouped under packages - see here for the automation packages documented in the user guide.

I have used the same package structure to make things easier for users of the framework.  For example, the "Repository" package, documented here in the user guide, has the corresponding wrapper module with namespace "ser.ea.repository", and a class element called "ser_ea_repository".  The class element implements a getModule() operation which returns the module object.

Types, Factories and Singleton Objects

Some of the Javascript code I've come across tends to mix classes/types, factory methods and object instances (often singletons).  The following conventions are probably not Javascript idiomatic and probably highlight my code structuring prejudices and idiosyncrasies.

  • Types, classes and creator functions are available as attributes of the module object for a particular namespace.  For example, within the namespace ser.ea.repository, the framework equivalent wrapper class is available as ser.ea.repository.RepositoryWrapper.
  • All modules within the framework have a factory class that can be used to create objects for the module - it is usually called "Factory" for every module.
  • If a module needs to expose singleton objects, these are provided in a separate, but consistently named ("context") namespace.  For example, the framework wrapper for the Repository object is available from ser.ea.context.

Comments

Post a Comment

Popular posts from this blog

Creating Items in Sparx EA via Java

-
Introduction This short post provides guidance on how to create "things" in a Sparx EA model via the Java API. Theory Creating "things" in EA via Java is driven by the Add New method and the Collection class. The first example in the code is adding a "view" to an existing root node. The code below will retrieve the root GUID if the "i" variable is set to 0; rootPackageID = rep . GetModels (). GetAt ( i ). GetPackageGUID (); After obtaining the root GUID it is possible to create a view under the root node. Note the process of retrieving the packages under the root and placing them in a collection. The Add New process is driven from the Collection. Importantly, for a view, the code needs to set a flag which indicates a particular icon. This process is only required for views. org . sparx . Package root = rep . GetPackageByGuid ( rootPackageID ); // get the root Collection < org . sparx . Package > subPackages = r...
Read more

Flexible Method Pattern

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

Traversing a EA Model via Java

-
Traversing an Enterprise Architect model from Sparx Systems is relatively simple. This blog introduces the concept of model traversal via the Java API. For information on Java Set-Up see this blog entry . The first step is to obtain the repository object as it provides the anchor from which all other operations are derived. In the example below, a repository is held on the file system. The variable "repoLocation" holds the file system location of the "eap" file.   rep = new Repository();  // get a repository   rep.OpenFile(repoLocation);  //open the repository file At the top of a model is a root node and it is typically where you want to start when traversing a model. From the root node you can then obtain a collection of packages. At this point, it is easy to traverse the collection pulling in the packages via a loop and in this example printing out their names. To see the complete example, go to GitHub .   org.sparx.Package my...
Read more