Skip to end of metadata
Go to start of metadata

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

Zend Framework: Zend_Dojo_Data - Envelope Component Proposal

Proposed Component Name Zend_Dojo_Data - Envelope
Developer Notes - Envelope
Proposers Matthew Weier O'Phinney
Zend Liaison TBD
Revision 1.0 - 19 June 2008: Initial Draft. (wiki revision: 5)

Table of Contents

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 format. 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 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


Specifying a Zend_Db_Table_Rowset


Specifying a service consumable


Specifying an array and using accessors

9. Class Skeletons



Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Jun 20, 2008

    <p>Great idea. I love it, how you (Matthew) integrates all this Dojo stuff. Great work!</p>


  2. Jun 20, 2008

    <p>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').</p>

    <p>What I'm missing is Zend_Dojo_Data implementing ArrayAccess. setItem(), getItem() and removeItem() are essentially the same as offsetSet(), offsetGet() and offsetUnset().</p>

    1. Jun 21, 2008

      <p>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:</p>
      <li>implementing toArray()</li>
      <li>Traversable objects (would traverse and cast each value)</li>
      <li>associative arrays</li>

      <p>Each item added would need to be either an assoc array or an object ( 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().</p>

      <p>I will update the proposal to indicate that the class will implement ArrayAccess, Iterator, and Countable – this was intended from the outset.</p>

  3. Jun 26, 2008

    <ac:macro ac:name="note"><ac:parameter ac:name="title">Zend Comments</ac:parameter><ac:rich-text-body>
    <p>This proposal has been approved for standard/incubator development as is.</p></ac:rich-text-body></ac:macro>