Skip to end of metadata
Go to start of metadata

Zend Framework: Zend_TagCloud Component Proposal

Proposed Component Name Zend_TagCloud
Developer Notes http://framework.zend.com/wiki/display/ZFDEV/Zend_TagCloud
Proposers Ben Scholzen
Zend Liaison Matthew Weier O'Phinney
Revision 1.0 - 21 November 2008: Initial Draft.
1.0 - 22 November 2008: Refactored to Zend_TagCloud. (wiki revision: 9)

Table of Contents

1. Overview

Zend_TagCloud is a simple component to create tag clouds from a simple array list of tags.

2. References

3. Component Requirements, Constraints, and Acceptance Criteria

  • This component will not limit the output to HTML.
  • This component will allow any kind of HTML output by default.
  • This component will let the user define the separator between the tags.
  • This component will allow to specify the min- and max-fontsize.
  • This component will allow to specify the unit for the fontsize.
  • This component will alternatively support a list of classes instead of fontsizes.

4. Dependencies on Other Framework Components

  • Zend_Exception

5. Theory of Operation

Zend_TagCloud is instantiated with an options array or Zend_Config object. You should at least supply an array of tags for the tag cloud to ronder. After that, you can call the $tagCloud->render() method or simply do "echo $tagCloud" via the magic __toString() method (not implemented in the prototype yet).

6. Milestones / Tasks

7. Class Index

  • Zend_TagCloud
  • Zend_TagCloud_Exception
  • Zend_TagCloud_Decorator_Exception
  • Zend_TagCloud_Decorator_Cloud
  • Zend_TagCloud_Decorator_Tag
  • Zend_TagCloud_Decorator_HtmlCloud
  • Zend_TagCloud_Decorator_HtmlTag

8. Use Cases

UC-01

9. Class Skeletons

Too much, see prototype: http://framework.zend.com/svn/framework/standard/branches/user/dasprid/TagCloud

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

14 Comments

comments.show.hide

  1. Nov 23, 2008

    Joó Ádám

    In a recent project I created my own cloud, in which I used an array which stored every tag with its number of occurrences. The output is an ordered list (tags are in alphabetical order), and the number of occurrences is in parenthesis after every tag. Also, a class 'weight*' is added where * is the number, and the corresponding CSS is generated for it. Finally a static CSS is applied, forming the 'cloud' itself (inline etcetera).

  2. Nov 25, 2008

    Dennis Becker

    I like the idea of a TagCloud component! What I miss so far is an example which shows how the array should look like.

    1. Nov 25, 2008

      Ben Scholzen

      Alright, added an example for the tags array.

  3. Nov 25, 2008

    Tobias Petry

    Adding TagClouds is a common "problem" in Web2.0 Apps, having a Zf component would be really nice.

    But i would prefer a public method like getCloud(array $tags) and the render-method should calculate the sizes by this method.
    Why? Maybe you have an environment where youe are not able to use an decorator for displaying the cloud: writing the cloud to a database, make cloud a SOAP-Response etc

    1. Nov 25, 2008

      Ben Scholzen

      This requires at least a tag decorator, which defines the weight values. But could be possible.

  4. Nov 25, 2008

    Benjamin Eberlei

    I think it should be a view helper. Additional decorators can be configured via optional parameters in the call signature. All other things are overkill for something that is inheritly a view helper, not a standalone component.

    I propose:

    Zend_View_Helper_TagCloud::tagCloud($tags, $tagDecorator=null, $cloudDecorator=null) where the 2nd and 3rd parameter null would use the default decorators.

    Another possibility would be to do it via one options parameter as in: Zend_View_Helper_TagCloud::tagCloud($options)

    1. Nov 25, 2008

      Ben Scholzen

      The last thing can easily be done:

      <?php echo new Zend_TagCloud($options); ?>

      alternatively, I could create a view helper which wraps around Zend_TagCloud, tho it result in kinda the same line, which is only 2 characters shorter:

      <?php echo $this->tagCloud($options); ?>

      1. Nov 25, 2008

        Ryan Mauger

        I ageree with Benjamin Eberlei,

        A whole component for this seems too much, and using it as a view helper in your view scripts would feel more natural.

        1. Nov 25, 2008

          Ben Scholzen

          Tho that would limit it to views only. Zend_Pdf for example couldn't use that view helper. Or also if you want to deploy a webservice which output tags with calculated values, a view helper would be the wrong way again.

      2. Nov 27, 2008

        Dolf Schimmel (Freeaqingme)

        I don't think this should be a view helper for the same reasons Zend_Form isn't a view helper.

  5. Dec 22, 2008

    Ralph Schindler

    I had an interesting idea for this proposal which might affect the actual naming.

    So basically, I had in the past created a component that exposed (much like acls), and interface so that any type of "model" could be "taggable".

    The Zend_Tagger component would be configurable, contain filters (for normalizing tag names, and through this configuration be able to store tag and "entry" information into a database. Think how Zend_Auth_Adapter_DbTable works- it would be quite similar in nature of configuration.

    This would allow for:

    Entries would simply have to return an identifier so that the tagger can be used like so:

    As for ben's propoals, would imagine it would be used like this:

    Thoughts?

  6. Dec 29, 2008

    Matthew Weier O'Phinney

    Zend Acceptance Criteria
    The Zend team accepts this proposal for development in the standard incubator, with the following changes:
    • Rename the component to Zend_Tag_Cloud
    • Provide a value object (and interface) that represents a Tag-ged item. This would contain methods for retrieving the title, weight, and URL of the tag, and could be used instead of array notation in order to simplify and enforce tags (it would not replace array notation, however).

    The purpose of these recommendations is to allow for a larger component in the future which would deal with managing all aspects of folksonomy tagging.

    Otherwise, we feel the proposal is ready as-is.

  7. Mar 18, 2009

    Wil Sinclair

    Ben, what is the status of this proposal? We'd love to see it in 1.8, but obviously Zend_Application is the priority.

    1. Mar 21, 2009

      Ben Scholzen

      Pretty much done, I currently let Matthew and Ralph review the API, and if everything is fine, writing the unit-tests and documentation.