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_Controller_Action_Helper_Autocomplete Component Proposal

Proposed Component Name Zend_Controller_Action_Helper_Autocomplete
Developer Notes
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: 5)

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:

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


9. Class Skeletons




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

    <p>Some first impressions:</p>

    <li>AutoComplete seems preferable to Autocomplete.</li>
    <li>The AutoComplete class and its <code>direct()</code> method should be abstract.</li>
    <li>Consider renaming <code>Zend_Controller_Action_Helper_DojoAutocomplete</code> to <code>Zend_Controller_Action_Helper_AutoComplete_Dojo</code> and a similar renaming for <code>Zend_Controller_Action_Helper_ScriptaculousAutocomplete</code>, or is there a problem with organizing action helpers into subdirectories?</li>

    1. Jan 09, 2008

      <p>Oops, maybe the <code>direct()</code> method cannot be abstract?</p>

    2. Jan 09, 2008

      <p>direct() can be abstract; I'll make that change.</p>

      <p>The main reason for naming them as <Library>AutoComplete is to make retrieving them as helpers simpler. It's the difference between:</p>
      <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
      <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
      <p>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. <ac:emoticon ac:name="smile" /></p>

      1. Jan 09, 2008

        <p>Yes, I was afraid that there was a method naming issue. I certainly don't want to suggest <code>$this->_helper->autoComplete_Dojo($data)</code>, 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.</p>

      2. Jan 09, 2008

        <p>Splitting hairs, I know, but i'd be happy with</p>
        <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[

        <p>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?</p>
        <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[

        1. Jan 09, 2008

          <p>I like the idea of autoComplete<LibraryName>. </p>

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

  2. Jan 10, 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 incubator development.</p></ac:rich-text-body></ac:macro>