Account confirmers, Anti-spam team, Confirmed users, Bureaucrats and Sysops emeriti
4,925
edits
Bugzilla:BzAPI:Objects:Configuration: Difference between revisions
Bugzilla:BzAPI:Objects:Configuration (view source)
Revision as of 09:50, 17 March 2010
, 17 March 2010no edit summary
No edit summary |
|||
| Line 4: | Line 4: | ||
* The idea is that this object is designed for easy lookup of values, so there are a lot of hashes, keyed by name or ID, instead of arrays over which one would have to iterate. | * The idea is that this object is designed for easy lookup of values, so there are a lot of hashes, keyed by name or ID, instead of arrays over which one would have to iterate. | ||
* This is also why many hashes are keyed by name rather than ID - it's because the name is more likely to be what the API user has. | * This is also why many hashes are keyed by name rather than ID - it's because the name is more likely to be what the API user has. You are, of course, at liberty to transform the data structures to key off something else. | ||
* The use of hashes also gives forwards-compatibility. For example, if some fields became product or component-specific, we could add a "fields" member to the hash. | * The use of hashes also gives forwards-compatibility. For example, if some fields became product or component-specific, we could add a "fields" member to the hash. | ||
* Classifications are not wrapped around their products in the same way that products are wrapped around their components because the use of classifications is optional, and this would make the top-level field name depend on whether they were switched on or not. | * Classifications are not wrapped around their products in the same way that products are wrapped around their components because the use of classifications is optional, and this would make the top-level field name depend on whether they were switched on or not. | ||