Design Specs: API

API Specs

Objects stop here -- what is passed to displays will be strings and numbers
Define data building blocks for common display formats -- lists, tables, build off these blocks
Provide consistent data access methods to above for display
Define common data packs? -- e.g. id and common names?
Analyze user reported data issues and build more robustness for common problems (e.g. object not found can't call method)

The API need not be aware of presentation details. It doesn't need to know about tables, for example, although it should handle generic one and two dimensional arrays.
We may want to consider passing some objects through to templates. If we pass WormBase::API objects, templates can then do additional on-the-fly data extraction.
We probably DON'T want to pass Ace objects. This means that your data munging subroutines will need to do something like:

 $allele = $gene->Allele;
 $returned_data => { data => "$allele" };

This will stringify the name of the object and prevent it from being passed as an object.

You can find the API in the WormBase mercurial repository:

lib/WormBase/API

There are tests in t/

cd WormBase // the directory where you've checked out your code
prove -l t/API/Object/Gene.t

These are obviously dependent on being able to connect to the database...

Issue	Pros	Cons
Let ACE objects through	minimal API programming	breaking the CVM barriers