Skip to end of metadata
Go to start of metadata
You are viewing an old version of this page. View the current version. Compare with Current  |   View Page History
New Proposal Template
This page has been created from a template that uses "zones." To proceed:
  1. Edit the page
  2. Replace sample content within each zone-data tag
  3. Remove this notice
  4. Save the page
  5. When you are ready for review, remove the Under Construction notice
Under Construction
This proposal is under construction and is not ready for review.

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

Zend Framework: Zend_xml2json Component Proposal

Proposed Component Name Zend_xml2json
Developer Notes http://framework.zend.com/wiki/display/ZFDEV/Zend_xml2json
Proposers Senthil Nathan
Revision 0.1 - 23 April 2007: Initial proposal. (wiki revision: 6)

Table of Contents

1. Overview

This is a proposal to add a new feature to the Zend_Json module. This new feature will provide a conversion capability. Specifically, it will allow any arbitrary XML formatted document to be converted into JSON formatted string. The following paragraph forms the motivation for this proposal.

Since the late 1990s, many enterprise data architectures have been using XML. That choice made it a common practice for mid-tier (PHP and J2EE) servers to exchange enterprise data with the browser applications in XML format. However, current popularity of JSON makes it a credible data interchange format between browser applications and mid-tier servers. Combined with the rising adoption of Ajax in enterprise-grade applications, JSON is emerging as a natural choice for data encoding at both the client and middle tiers. The key reason being that there is no extra parsing required in the browser applications to interpret JSON formatted data. Because, JSON is readily consumable in browser applications as it follows the data syntax rules of JavaScript. In addition, JSON makes the job of the browser application developers a lot simpler by eliminating the need to deal with all the intricacies of XML.

As Web 2.0 technologies proliferate in large enterprises, it will become necessary for PHP-based mid-tier server applications to exchange enterprise application data with the browser applications in JSON format rather than in XML format. In order to achieve this, server-side PHP application developers have to convert XML-formatted data into JSON-formatted data before sending it to browser. In reality, it would be extremely beneficial to make this conversion as part of the Zend Framework. Hence, this proposal is made to add this simple, but powerful feature in the Zend_Json module.

2. References

3. Component Requirements, Constraints, and Acceptance Criteria

Most requirements take the form of "foo will do ...." or "foo will not support ...", although different words and sentence structure might be used. Adding functionality to your proposal is requirements creep (bad), unless listed below. Discuss major changes with your team first, and then open a "feature improvement" issue against this component.

  • This component will correctly reads a developers mind for intent and generate the right configuration file.
  • The generated config file will not support XML, but will provide an extension point in the API.
  • This component will use no more memory than twice the size of all data it contains.
  • This component will include a factory method.
  • This component will not allow subclassing. (i.e. when reviewed, we expect to see "final" keyword in code)
  • This component will only generate data exports strictly complying with RFC 12345.
  • This component will validate input data against formats supported by ZF component Foo.
  • This component will not save any data using Zend_Cache or the filesystem. All transient data will be saved using Zend_Session.

4. Dependencies on Other Framework Components

  • Zend_Exception

5. Theory of Operation

The component is instantiated with a mind-link that ...

6. Milestones / Tasks

Describe some intermediate state of this component in terms of design notes, additional material added to this page, and / code. Note any significant dependencies here, such as, "Milestone #3 can not be completed until feature Foo has been added to ZF component XYZ." Milestones will be required for acceptance of future proposals. They are not hard, and many times you will only need to think of the first three below.

  • Milestone 1: design notes will be published here
  • Milestone 2: Working prototype checked into the incubator supporting use cases #1, #2, ...
  • Milestone 3: Working prototype checked into the incubator supporting use cases #3 and #4.
  • Milestone 4: Unit tests exist, work, and are checked into SVN.
  • Milestone 5: Initial documentation exists.

If a milestone is already done, begin the description with "[DONE]", like this:

  • Milestone #: [DONE] Unit tests ...

7. Class Index

  • Zend_Magic_Exception
  • Zend_Magic (factory class)
  • Zend_Magic_MindProbe
  • Zend_Magic_MindProbe_Intent
  • Zend_Magic_Action
  • Zend_Magic_CodeGen

8. Use Cases

UC-01

... (see good use cases book)

9. Class Skeletons

]]></ac:plain-text-body></ac:macro>

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.