Labels
Zend Framework: Zend_Dojo_Data - dojo.data Envelope Component Proposal
| Proposed Component Name | Zend_Dojo_Data - dojo.data Envelope |
|---|---|
| Developer Notes | http://framework.zend.com/wiki/display/ZFDEV/Zend_Dojo_Data - dojo.data Envelope |
| Proposers | Matthew Weier O'Phinney |
| Zend Liaison | TBD |
| Revision | 1.0 - 19 June 2008: Initial Draft. (wiki revision: 4) |
Table of Contents
- 1. Overview
- 2. References
- 3. Component Requirements, Constraints, and Acceptance Criteria
- 4. Dependencies on Other Framework Components
- 5. Theory of Operation
- 6. Milestones / Tasks
- 7. Class Index
- 8. Use Cases
- Specifying a Zend_Db_Table_Rowset
- Specifying a service consumable
- Specifying an array and using accessors
- 9. Class Skeletons
1. Overview
Dojo and other Javascript toolkits are often choosing to abstract data access for their widgets in order to allow switching data sources. Dojo does this via a variety of data stores, which consume data in the dojo.data format. dojo.data is a simple format for wrapping data sets and providing basic metadata about them:
To dissect this in PHP terms, we have a structure like the following:
When using Zend Framework, however, you will rarely have a data construct that matches this. This proposal would provide a component that could consume a variety of data constructs to utilize as dojo.data items, and mutators for specifying the identifier and optional label attributes of the records in the data store. Additionally, accessors would allow for retrieving the information.
This component could then be used as a backend data store for use with Dojo's QueryReadStore. This would require serialization of the data and metadata stored in the object to JSON (which is consumed natively by QueryReadStore). While dojo supports other data stores, these data stores utilize special formats already and will not require usage of this component. As examples, the CsvStore, OpmlStore, and AtomStore all leverage the self-documenting capabilities of those formats in order to provide introspection of the returned data. The only other format of much interest to ZF developers might be the XmlStore. This store allows parsing of arbitrary XML collections. However, it's a read-write store, and would be best used with public, editable XML documents.
2. References
3. Component Requirements, Constraints, and Acceptance Criteria
- MUST allow attaching arbitrary data sets:
- Zend_Db_Table_Rowset_Abstract
- Arrays
- Service results
- MUST require specifying identifier attribute name
- MUST require specifying label attribute name
- MUST provide accessors and mutators to data items
- MUST serialize to JSON
- SHOULD implement string serialization proxying to JSON serialization
- MUST allow access to metadata and data within PHP
4. Dependencies on Other Framework Components
- HARD depedencies
- Zend_Exception
- SOFT dependencies
- Zend_Db_Table_Rowset_Abstract
- Potentially Zend_Service consumables
5. Theory of Operation
A developer will attach a data set and specify an identifier when instantiating Zend_Dojo_Data; alternately, these can be specified via mutators. Serialization will happen on demand via a toJson() method.
6. Milestones / Tasks
- Milestone 1: [DONE] Prepare this proposal
- Milestone 2: Prepare test suite and API
- Milestone 3: Complete initial implementation
- Milestone 4: Write documentation
7. Class Index
- Zend_Dojo_Data
- Zend_Dojo_Data_Exception
8. Use Cases
| UC-01 |
|---|
Specifying a Zend_Db_Table_Rowset
| UC-02 |
|---|
Specifying a service consumable
| UC-03 |
|---|
Specifying an array and using accessors
9. Class Skeletons
Which types are supported as items? Only arrays or also objects (maybe with a toArray() method) and scalars (with an implicit attribute name 'value' or 'scalar').
What I'm missing is Zend_Dojo_Data implementing ArrayAccess. setItem(), getItem() and removeItem() are essentially the same as offsetSet(), offsetGet() and offsetUnset().
If you look at the examples, the primary use case I suggest is a Zend_Db_Table_Rowset. However, I'll likely go the same route as with partials, and have the following criteria:
- objects
- implementing toArray()
- Traversable objects (would traverse and cast each value)
- associative arrays
Each item added would need to be either an assoc array or an object (dojo.data items are JS objects). If an object is passed as an item, it will either need to implement toArray(), or we will use get_object_vars().
I will update the proposal to indicate that the class will implement ArrayAccess, Iterator, and Countable – this was intended from the outset.
ZF Home Page
Code Browser
Wiki Dashboard
Great idea. I love it, how you (Matthew) integrates all this Dojo stuff. Great work!
Remi