| title |
|---|
Make File Details |
The name of the file without extension is the make_id. For example ccd.yaml has a make_id of ccd. http://make.cape.io/ has an index of the make files in the currently public github repo.
Typically the make_id can be used to access the data/site via the CAPE rendering server by using it as the subdomain. For example http://ccd.cape.io
This should be the current "live" domain name. A server entry on the rendering server will be created that points this domain to the correct directory (v2.cape.io/{make_id}).
The CAPE user ID to use for authentication with the various providers listed in the file. The user must link accounts like dropbox or github in order for CAPE to have access to that information.
Define the version of CAPE that this make file is compatible with.
[You'll have to visit the links manually on your own for now.]
A list of urls that get called in sequential order when you visit http://v2.cape.io/{make_id}/_load
A Data API definition defines how to access a collection of entities. Sometimes called a content repository or database. Defining an API subscribes to the provider and listens for updates according to the arg object.
Example Providers:
- Github Repository
- Instagram Photos
- Facebook Posts
- Twitter Posts
- Dropbox Folder
An API need only have access to an "Entity ID". If it does have access to an object the field id for that object is _source by default. You can change that field id by adding a _source field to the API definition and making the value a text string. That text string will become the field ID. The most common value is _self. See the Model section for details.
A data model is a list of filtered (and sometimes modified) entities based on a specific API. The collection is filtered based on must, must_not, and should statements. Essentially a query against a collection. Normally it is a field and value are specified and it must match exactly. In other cases special methods are enabled for more advanced comparisons. The field value is passed through the method and the result is then compared to the value in the view.
A model is saved as a list of ID's.
Entities are automatically given some values when appropriate. See the Entity Meta fields section above. These can be used in the filters.
Views convert the data Model into a display of some kind. A view can output HTML generated by passing a model into a template. A view can also be a data object that simply changes the values of a data Model.
Views can filter the results of a data Model. They can also limit the results and paginate results.
Defines a theme file that the entities are passed through.
A unit (node) of content. Entities can be documents, media, feed items. Just about anything can be an entity. The only required field of an entity is an ID.
Entities are not defined in the make file but they are the thing being created, filtered, sorted, and rendered. Entities always belong to a specific API.
It is useful during the model process to have extra fields available for comparisons.
Example ID: path/to/file/example.txt
_ext- Includes the dot! Example:.txt_no_ext- Full ID without the ext. Example:path/to/file/example_basename- Filename with the ext. Example:example.txt_filename- Filename without ext. Example:example_dirname- Path to file. Example:path/to/file_dirsplit- Array of directory. Example:['path', 'to', 'file']_dir1-path_dir2-to_dir3-file
Models can define additional fields for the entity. Special field IDs:
- _self: Each property of this field is added to the base when rendered.
_self.titlebecomestitle. - _file: This saves the value as a file. Useful for attaching images to an entity.
Model entities filtered based on the list status. Simple lists use a status field on the entity itself.
Model entities that HAVE value added.
Model entities that HAVE value removed.
Model entities that are NOT in the list. DO NOT have value added or removed.
Model entitites that do NOT have value removed.