I can't see any mention of it in the API Blueprint spec, although there was a feature request to add an include directive for including other files.
Include is not to be confused with the non-standard directive of the same name for including other files (although the aglio tool for API Blueprint does support the latter).
Include is defined in the MSON specification, which is referred to by the API Blueprint spec. For example, in the Data Structures section of an API Blueprint file, the named types defined therein are defined using MSON.
Include is like extends in Java - it makes the type that is currently being defined inherit all the fields of the specified "supertype". The keyword Include may be followed by the name of a named type (its usual usage) or, somewhat strangely, by an inline type definition:
MSON defines a Mixin Type that supports multiple inheritance from
another Named Type. The Named Type being inherited MUST be a Structure
Type or its sub-type.
Nested Member Types defined in and inherited from the mixed-in Named
Type are added at the same indentation level of the Mixin Type.
Mixin Type → - Include Type Name | - Include Type Definition
Related
In my use case I have a RAML 1.0 library created by our R&D department that contains definition of multiple data types. Those data types are defined in a generic, parametrized manner so when I reference them in my RAML I do so using following syntax:
type: { resourceTypes.collectionWithCriteria: {itemName: reward, itemCriteria: types.RewardCriteria, itemType : types.RewardList} }
This generates proper GET request with query string defined by types.RewardCriteria and response defined by types.RewardList. It also generates the description for the GET resource defined as: Retrieves the list of <<itemName | !pluralize>>, which ends up being Retrieves the list of rewards.
In my RAML I would like to append additional description to my GET resource, however I 'd rather avoid overwriting library-generated one. Is that possible? I've already tried inline description and using overlay file, both of which simply replace description from the library.
You cannot append for a single value simple property.
The merging rules for traits / resource types state that the description will be replaced:
Every explicit node wins over the ones that are declared in a resource
type or trait. The rest are simply merged.
Also, the merging rules of overlays and extensions states that:.
If the property is a Simple Property
If the property is a Single-value Simple Property,
The property value in the identically named Current Target Tree Object property is replaced with its value from Current Extension Tree Object property.
Is lib a special keyword for Frogatto Formula Language (FFL)? That seems to be the way of invoking class methods. For example:
where frog = lib.citadel.create_creature('Giant Frog')
Also, I am interested to know where can I find a list of all the available lib.**** library objects and how to list of all their available functions.
I wouldn't call it a keyword as such, more a symbol that appears in the standard namespace. As such it is functionally fairly close to a keyword.
When you create a class by adding a file e.g. data/classes/blah.cfg then a singleton instance of this class will be available using lib.blah. This is a convenient way of effectively creating your own namespace of functions -- create a class, add functions to it, then your functions can be accessed using lib.classname.functionname()
I am reading GO's text/template doc and confused by these following description.
https://golang.org/pkg/text/template/#Template
Each template is named by a string specified when it is created. Also, each template is associated with zero or more other templates that it may invoke by name; such associations are transitive and form a name space of templates.
.
By construction, a template may reside in only one association. If it's necessary to have a template addressable from multiple associations, the template definition must be parsed multiple times to create distinct *Template values, or must be copied with the Clone or AddParseTree method.
How can template association be transitive but then it can only reside in one association? Some examples will be greatly appreciated.
I'd like to access attributes that are inside instances of defined types from other classes/instances.
This is very similar to a question asked on SO before - In Puppet, how can I access a variable/attribute inside a defined type?, however from what I understood the answer was specifically related to accessing parameters as opposed to arbitrary variables.
For example, given the following defined type:
define server (
$server_name = 'my_server'
){
$server_history = 'A long story'
}
I can successfully use getparam(...) to fetch server_name but I cannot do the same for server_history.
Also, if server was a class as opposed to to a defined type, accessing this variable is straightforward using something like server::serverhistory
Does anyone have any ideas on how to expose these variables? Or am I approaching this completely the wrong way?
Edit: For some higher level context on what I'm trying to do my server type gets instantiated by 3 other classes. A variable in the server type builds out some directory paths based on parameters provided to it by these classes (which naturally, are specific to those classes). There are some other classes that would like to use the directory path variable to place files there.
You ask
I'd like to access attributes that are inside instances of defined types from other classes/instances.
and you go on to clarify that you're after
arbitrary variables.
In fact, ordinary variables in the body of a defined type are not attributes of that type, nor of any instance thereof. They are not part of the accessible persistent state of instances of such types at all.
More generally, Puppet treats defined types just like native types in almost every observable way, but by the same token, it does not provide any features that serve to distinguish defined types as a special case. You are looking for such a feature, and it does not exist.
Since your design idea will not work, you'll need to think of an alternative. You say
my server type gets instantiated by 3 other classes. A variable in the server type builds out some directory paths based on parameters provided to it by these classes (which naturally, are specific to those classes). There are some other classes that would like to use the directory path variable to place files there.
Since the paths you're after are characteristic of specific classes, it makes sense for them to be accessible directly via those classes. It seems odd to me that you would even want to access them indirectly via resources declared by those classes.
I've been using mogenerator for a while now, and while there is a reasonable Getting Started Guide and a Stack Exchange article on the command line options, I haven't found a good guide for all of the functionality it provides.
In short: what, above and beyond the classes that Core Data provides for you, what does mogenerator actually generate?
(Frankly, I kept finding little pleasant surprises in the headers/implementations that I didn't realize were in there and I decided to step through the mogenerator templates and code and document what I found in a Stack Exchange Q&A. I'd love to see additional answers and edits, however. )
In addition to its core feature of a two class system, mogenerator helps you by automatically implementing a number of best practices regarding Core Data in your machine header and implementation files.
Property Accessors
Methods to access the attributes of your Entities are the core of what mogenerator generates. But there are some nice features implemented in the accessors above and beyond what the out of the box Xcode class generator provides to you.
Scalar Accessors
Xcode's built in generator gives you the option of "use scalar properties for primitive data types". This option gives you choice of having Xcode create properties with NSTimeIntervals instead of NSDates for date types, BOOLs instead of NSNumbers for boolean types, and int16_t (or similar) rather than NSNumbers.
I find this infuriating because most of the time I prefer the primitive types, but not for NSDates which are much more useful than a NSTimeInterval. So Core Data is giving me the choice of objects, in which case I will be constantly unboxing stuff and making stupid mistakes like if(myBooleanAttribute) (which is always YES because myBooleanAttribute is a NSNumber, not a BOOL). Or I can have scalars, but in that case, I get NSTimeIntervals that I'll always have to convert to NSDates. Or I can hand edit all of the generated files by hand to give me my desired mix of NSDates and BOOLs.
On the other hand, mogenerator provides you with both options. For example, you will get both a myBooleanAttribute getter that gives you an NSNumber (for easy storage in an NSArray) and a myBooleanAttributeValue getter that gives you an actual BOOL. Same with integers and floats. (Mogenerator does not generate NSTimeInterval accessors: only NSDates.)
Typed Transformable Properties
If you have a transformable property, you can set a specific UserInfo key ( attributeValueClassName ) in the attribute that will specify the class that your property will return/accept. (And it will properly forward declare the class etc.) The only place I found this documented was on Verious.
In contrast, the Xcode code generator will only type these transformable attributes as id types.
Validation Declaration
While mogenerator does not automatically generate any validation methods, it does include the proper signature as a comment in the machine h file. The seems to largely be for historical reasons, but it does mean that it is easy to copy and paste the signature if you decide to implement it in your human file implementation. (I wouldn't actually uncomment the declaration as you aren't supposed to call validation directly.)
Primitive Accessors
Core Data already provides you these accessors to the primitive values, but for some reason doesn't include them in its Xcode generated headers. Having mogenerator include them in its header files makes it much easier to access a primitive value.
Fetched Properties
mogenerator will generate accessors for fetched properties. As far as I can tell there is no way to have the Xcode generator do this.
Helper methods
Automatic NSFetchedResultsController generation
If you have a to many relationship in your Entity and you pass --template-var frc=true into mogenerator, mogenerator will automatically generate a method to create a fetch request for the child objects associated with a parent object. It even automatically generates a unique cache name, and isolates everything inside an #if TARGET_OS_IPHONE preprocessor macro.
Even if this doesn't fit your particular needs, it is a great example of how the templates can be extended.
+fetchMyFetchRequest:moc_
If you like defining your fetch requests in the model, this is a lot better way to retrieve them than hardcoded strings.
-MyEntitySet
Mogenerator uses the magic of KVC to give you a NSMutableSet proxy into your relationships.
+entityName
Need to provide a entity name to a NSFetchRequest or other Core Data method? It's easy to avoid hard coded strings by using this simple method that returns the name of the entity as an NSString.
+insertInManagedObjectContext: and entityInManagedObjectContext:
Another way to avoid hardcoding entity names is to use these helper methods.
Typed object ids
Each of your headers and implementations also includes a MyEntityID class. They are empty interfaces and implementations that merely subclass the NSManagedObjectID class. Also, each model class has a helper method called objectID that overrides the standard objectID method in NSManagedObject. The helper method does nothing but cast the superclass's return value to the MyEntityID type.
The net result: the compiler can catch your mistakes if you ever accidentally interchange your object ids from different entities.
Miscellaneous
Subclassing a Custom Superclass
One of the command line options is --base-class: which allows you to specify a base class that all of your generated classes will inherit from. This is very useful, either so that you can have a base class where you define convenience methods (which, given Core Data, you probably should) or so you can use an off the shelf Core Data toolkit like SSDataKit (or both).
includem
A simple little thing, but if you specify a --includem argument, mogenerator will generate a header file that includes all of your model header files. Convenient if you want to include all of your headers in a PCH, or something some other standard header you include.
Const Definitions of All Attributes, Relationships, Fetched Properties
An extern declaration of a struct is included in the header that has an NSString defined for every attribute and relationship defined in your Entity. This allows you to define predicates and other parameters, without baking the names of your entities into your strings. For example,
req.predicate = [NSPredicate predicateWithFormat:
#"(%K == YES) AND (%K <= %#)",MyObject.favorite, MyObject.availableDate, [NSDate date]];
(This type of struct used for "namespaced" constants is described My Mike Ash on his blog
const Definitions of User Info Keys/Values
Similarly an extern declaration of a struct is defined in the header that includes the keys as members of the struct, and the values as a values. i.e.
NSLog(#"User info for key my key is %#",MyObjectInfo.mykey) //will log "myvalue"
Alternate Templates
One of the interesting things about mogenerator is that in building mogenerator its author (Wolf Rentzsch) has basically built a generic parser and templating engine for the xcdatamodel files produced by Xcode. So you don't need to use the mogenerator templates. You can provide your own with a simple command line argument. There are lots of user contributed templates on the GitHub site.
In fact, you don't even have to use Core Data. Many of the contributed templates allow you to generate a series of ordinary NSObject model classes based on the data model. (So called PONSOs: "plain old nsobjects"). Want to use the data modeler in Xcode, but some other persistence mechanism? mogenerator can help you there.
You don't even need to generate objects at all: another interesting submitted template just provides a diff of two different model versions.