GWT

Layer Definition Files

You define a new layer by creating a layer definition file in a source directory in your layer path. The layer definition file is an ordinary StrataCode file named with the directory name. E.g. foo/foo.sc, foo/bar/bar.sc

The layer definition file contains a modify definition where the type is the layer definition file's path in the layer path.

--- foo/foo.sc:
foo {
}

and:

--- foo/bar/bar.sc:
foo.bar {
}

Running the scc Command

When you run the scc command, you specify a list of layers to run: e.g.

scc foo

or

scc foo/bar

That list maps to layers in your layerPath. By default the layer path includes the current directory or you can set it via the -lp option.

As a convenience, you can also run a specific layer when you are in that layer's directory using . as the name of the layer.

% cd foo/bar
% scc .

Layer Packages

When the layer definition file specifies a package, that package is used as the top-level package for all files in that layer. In other words, a file in the layer's directory will be in that package. You can omit the package line in your .java and .sc files and StrataCode will insert it for you automatically and create the empty directories during compilation.

If the layer does not specify a package, it inherits the package from the first layer in its extends list which exports its package. A layer can disable inheriting its package with:

foo {
   inheritPackage = false;
}

A layer can disable exporting its package with:

foo {
   exportPackage = false;
}

In general application layers work in the same package so use the default.

Note that a layer with no package is effectively global and can customize any type. You may need to set "inheritPackage = false" to make a global layer however.

Processes and Runtimes

StrataCode supports multiple runtimes - 'java', 'js', 'android', and 'gwt'. Some layers are suitable for any runtime but some have restrictions. Layers can set constraints by including or exclude runtimes. By default a layer picks up the constraints from it's base layers unless those constraints conflict - in which case it's put in any runtime allowed by one of it's base layers. So if a layer extends both 'js' and 'java' base layers, without including or excluding runtimes on its own, it's put in both runtimes.

In some cases a given runtime will have more than one process. For example "DesktopJava" versus "ServerJava". Just as a layer specified runtime constraints, it can specify process constraints.

Once a block of layers are activated, StrataCode determines the set of separate processes/runtimes required and generates a list of separate layer stacks, one for each including the appropriate layers.

For the most part application layers will establish their constraints by extending the framework layers they require. When it's necessary to customize placement in a runtime, you can add an includeRuntime or excludeRuntime method call to the layer definition file. It's important to run this in the initialize method (or it's also ok to put it in an instance scoped statement block).

Because StrataCode needs to create and initialize the layer to determine its constraints, each layer will get initialized at least once in the default runtime. If it does not belong in that runtime, it's marked with "excluded = true". That layer instance is used to determine which other runtimes it's included in and new Layer instances are created for each of those runtimes.

The Layer.start method will never be called on an excluded layer.

Configuring Builds

In StrataCode, layer definition files also specify build and other properties but typically only for framework layers. They are interpreted Java files, run in the order in which the layers are present in the system. They are initialized in three phases, via initialize, start and validate methods which lets them set and override properties in a layered order.

These layer definition files configure the file types which are processed by the system, add to the classpath, add src folders, specify inherited imports, and set defaults for the code that run in the layers: e.g. public, and enable/disable system features per-layer.

Most systems require that you copy complex build and project setups into your environment that you must manage. With layers, you only store your customizations, even for project configuration.

Activating Layers

Layers are loaded either in the inactive or active state. An inactive layer is used for code navigation and editing operations in the IDE or to style code for producing the documenetation.

Inactive layers are started like regular active layers but the activated flag is set to false. Do register file processors and class path entries for inactive layers but do not adjust properties of the LayeredSystem that apply to build or your inactive layer will have unwanted side effects.

For more info, see the documentation on the build and runtime system;

For Java apis, see Layer, and LayeredSystem.