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

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

<p>But i would prefer a public method like <em>getCloud(array $tags)</em> and the render-method should calculate the sizes by this method.<br />
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</p>

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

<p>I propose:</p>

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

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

<p>I had an interesting idea for this proposal which might affect the actual naming.</p>

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

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

<p>This would allow for:</p>

<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
class BlogEntry implements Zend_Tag_Entry_Interface {
public function getEntryId() {}
}
]]></ac:plain-text-body></ac:macro>

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

<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
$tagger = new Zend_Tagger($config);
$tagger->tag($entry, array('Tag1', 'tag 2', 'some other tag');
]]></ac:plain-text-body></ac:macro>

<p>As for ben's propoals, would imagine it would be used like this:</p>

<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
<?= $this->tagCloud($options); ?>

//or

<?= $this->tagCloud($tagger); // see above ?>
]]></ac:plain-text-body></ac:macro>

<p>Thoughts?</p>

<ac:macro ac:name="note"><ac:parameter ac:name="title">Zend Acceptance Criteria</ac:parameter><ac:rich-text-body>
<p>The Zend team accepts this proposal for development in the standard incubator, with the following changes:</p>

<ul>
<li>Rename the component to Zend_Tag_Cloud</li>
<li>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 <em>replace</em> array notation, however).</li>
</ul>

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

<p>Otherwise, we feel the proposal is ready as-is.</p></ac:rich-text-body></ac:macro>

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