projections structure

This page shows possible projection structure and is subject to change once actual implementation is in place. This structure is shared by all the different projection kinds. Here's what it looks like:

Put into words: FieldsTree is a bunch of fields with further projections. Every field is described by a FieldBranch which holds actual Field instance, field parameters and field models. ModelsTree is a map from selected models (representations) to corresponding sub-projections described by ModelBranches. ModelBranch has special implementations for different kinds of models, one of them being RecordModelBranch which recursively brings us back.

You probably noticed FD, MD and PD type parameters. These are our extension points, abstract types that allow to attach arbitrary data to projection tree nodes. Once we specify these types we get a concrete projection flavor.

Two examples of such flavors are request projections that are created at the request time, and operation projections that are part of service description (IDL). They are the same topologically, i.e. they have the same branching points. Their payload is, however, different.

Imagine we have an operation that builds a FileRecord with name and comments fields, and for comments we support sort parameter. Operation projection should capture parameter value model and if it’s mandatory or optional, so PD will be something like

{
  model: Model,
  required: Boolean
}

Request projection should capture actual parameter value (if specified), so PD is simply a data container for parameters.

Example of operation projection in a pseudo-DSL:

(
  FileRecord.name,
  FileRecord.comments.as(
    Param("sort", BooleanPrimitive, required=false),
    FileCommentRecord.as(
      FileCommentRecord.text
    )
  )
)

Example of request projection as a string:

(name, comments;sort=true(text))