Difference between revisions of "Design Specs: API"
From WormBaseWiki
Jump to navigationJump to search (New page: 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...) |
|||
Line 1: | Line 1: | ||
− | + | ==API Specs== | |
− | API Specs | ||
* Objects stop here -- what is passed to displays will be strings and numbers | * Objects stop here -- what is passed to displays will be strings and numbers | ||
Line 7: | Line 6: | ||
* Define common data packs? -- e.g. id and common names? | * 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) | * Analyze user reported data issues and build more robustness for common problems (e.g. object not found can't call method) | ||
+ | |||
+ | === Notes 2010.02.04 === | ||
+ | * 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. | ||
+ | |||
+ | |||
+ | == Resources == | ||
+ | |||
+ | 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... |
Revision as of 12:13, 4 February 2010
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)
Notes 2010.02.04
- 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.
Resources
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...