Zend Framework: Zend_Controller_Action_Helper_Autocomplete Component Proposal
| Proposed Component Name | Zend_Controller_Action_Helper_Autocomplete |
|---|---|
| Developer Notes | http://framework.zend.com/wiki/display/ZFDEV/Zend_Controller_Action_Helper_Autocomplete |
| Proposers | Matthew Weier O'Phinney |
| Revision | 0.8.0 - 08 January 2008: Initial proposal creation 0.9.0 - 09 January 2008: Updated with feedback from Zend team and comments (wiki revision: 4) |
Table of Contents
1. Overview
Zend_Controller_Action_Helper_Autocomplete is intended to automate creation and transmittal of a response for use in client-side autocompletion.
2. References
In no particular order:
- Ajax.Autocompleter in Scriptaculous
- Autocompletion in YUI
- Autocompletion in Dojo
- Autocompletion in JQuery
3. Component Requirements, Constraints, and Acceptance Criteria
- This component will provide an abstract class for handling autocomplete resultsets.
- This component will provide one or more concrete implementations for returning autocomplete resultsets to specific client-side JS libraries.
- This component will set appropriate headers and the response body with the resultset.
4. Dependencies on Other Framework Components
- Zend_Controller_Action_Helper_Abstract
- Zend_Controller_Response_Abstract (for setting response headers and content)
- Zend_Controller_Action_Helper_Json (for serializing JSON resultsets and setting response headers)
5. Theory of Operation
Autocompletion allows type-ahead type functionality for HTML text input, providing users with options that may match the input they've typed. There are many ways to provide such functionality on the server-side, including:
- Returning HTML unordered lists (Prototype/Scriptaculous)
- Returning JSON arrays-of-arrays (YUI)
- Returning JSON objects (basically arrays-of-arrays) (Dojo)
- Returning JSON array-of-strings (JQuery)
Due to the variety of return types, no one component may serve all scenarios. However, the base functionality is relatively the same: take an array or iterable resultset of data, and transform it to the appropriate return value.
The Autocomplete helper will provide an abstract class for the base operations, including serializing the data to JSON return values. Concrete classes will thenformat the return value for the appropriate library.
6. Milestones / Tasks
- Milestone 1: [DONE] Complete proposal
- Milestone 2: Write tests and code and publish to incubator
- Milestone 3: Write documentation and use cases
- Milestone 4: Publish to core
7. Class Index
- Zend_Controller_Action_Helper_AutoComplete_Abstract
- Zend_Controller_Action_Helper_AutoCompleteDojo
- Zend_Controller_Action_Helper_AutoCompleteScriptaculous
- Zend_Controller_Action_Helper_AutoCompleteJquery
8. Use Cases
| UC-01 |
|---|
9. Class Skeletons
Zend_Controller_Action_Helper_Autocomplete_Abstract
direct() can be abstract; I'll make that change.
The main reason for naming them as <Library>AutoComplete is to make retrieving them as helpers simpler. It's the difference between:
and
The latter may be more semantically correct in terms of class hierarchy, but is harder to type and less intuitive. I'm open to the idea; I just don't like how it looks. ![]()
Yes, I was afraid that there was a method naming issue. I certainly don't want to suggest $this->_helper->autoComplete_Dojo($data), for example, as it does not comply with our method naming conventions, but it may make sense to think about this problem, as it is possible that we could have many action helpers that need to be organized with directory structure.
Splitting hairs, I know, but i'd be happy with
Is there any need to tie these helpers directly to a product, though? Since many libraries share similar solutions they would be better served by a naming scheme tied to the output method instead?
I like the idea of autoComplete<LibraryName>.
As for tying them to the product, actually, yes, it's necessary. I have yet to see two implementations that are the same – the format of the JSON array/object can vary, Scriptaculous returns an HTML unordered list, etc. I think having the names will make it clear which library they work with; if two use the same format, we can create a base class for that format and extend it with library specific-named classes.
ZF Home Page
Code Browser
Wiki Dashboard
Some first impressions: