ANNOTATION DOMINATION

When I do CAP and RAP stuff, I often feel the weakest part of my mental model is the annotation layer. I think it’s that declarative style…I’m more accustomed to telling the computer how to do a thing, and annotations are all about the what. It kind of makes it hard to trace a full cause-and-effect path between an annotation that the syntax checker is OK with but doesn’t seem to do anything.

So here are some of the things I do to help untangle myself. I offer these to anyone just dropping into this approach having that familiar “what the heck is going on?” feeling.

• Remember and follow the chain: one line in CDS -> a block of OData metadata -> automatic UI controls. If the UI isn’t doing what you think it should, look at the metadata the service outputs. Does it have the stuff you expect in it, in the places you expect? Then follow it back to the annotations themselves.

• You can put annotations in a couple of different places in the structure of an application. I find it easier to set up a one-stop-shop for the annotations early in the development process, to help me keep better awareness of all the pieces.

• Comment your annotations in the same style you comment your procedural code.

• Instead of reading my boring, meandering prose, just go learn from the master, DJ Adams.

Annotate away, friends. PM