<p>This is pretty cool, and I am loving it already. <ac:emoticon ac:name="smile" /></p>

<p>Now my question is - any plans to also "create" microformats? E.g. - let's say I want to spit out hcard, or generate xfn data? I know most if not all of the microformats are dead simple, but I guess it can never get too simple.</p>

<p>Hi Till,</p>

<p>Yep, the plan is to also generate microformatted data as HTML/XHTML/XML. I'll be adding some use cases for those once I have a firmer fix on the range of inputs. I suspect Zend_Config will be present here, but I don't want to rule out leaving Zend_Config as a factory method input, with individual microformats having their own designated OO APIs for appending data.</p>

<p>If necessary I'll make a few assumptions about a reasonable API for some use cases, and wait for my completion of Zend_Microformat_Xfn's proposal to visit specific APIs.</p>

<p>A few questions remaining:<br />
How do you plan to actually make the result accessible? Is the result of Zend_Microformat::findAll() an array or a comfortable object tree with iterators and accessors (yes, I have a preference here :-P)?<br />
Which microformats will be implemented in the first feature set?<br />
How is the relation to Zend_Feed_*, as e.g. hAtom is pretty similiar and should maybe reuse the consumption objects?</p>

<p>To clarify this: Zend_Microformat_hAtom should maybe reuse some Zend_Feed-parts. That's what I wanted to say.</p>

<p>Hi Lars,</p>

<p>I'll be working on those use cases today. My intention is probably your preference - a predominantly OO interface that is both iterable and countable. The result from findAll() will be a very simple object where the results are segregated as in:</p>

<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
$mf = new Zend_Microsoft('http://www.example.com');
$mfs = $mf->findAll();
$xfn = $mfs->xfn;
foreach($xfn as $data) {
// ...
}
]]></ac:plain-text-body></ac:macro>

<p>Once the use cases up, I'll wait for community comments and see what changes should be incorporated into my own initial pass.</p>

<p>Zend_Microsoft??? ROFL! I need to get off this laptop pronto...</p>

<p>After recovering from MS mentions...</p>

<p>I have added several more Use Cases showing example uses of finding and using results from Microformat queries. I've also added some generation Use Cases. As noted in the proposal, these have no one specific style, and the OO accessor and generator depends entirely on the specific Microformat in use. For consistency, these new uses cases assume we're using hCard.</p>

<p>Brilliant, looks very cool! I've been tinkering with microformats and the opening of the social graph lately. Thought about starting/joining a proposal for building a FOAF parser for ZF. Could do well with Microformats, particularly XFN.</p>

<p>Any knowledge of existing proposals/suggestions to do this in ZF?</p>

<p>I'm very interested to see this develop; I use microformats all over the place in my projects.  One thing, though...the proposal indicates that this class can be used to programatically generate and output microformatted HTML/XHTML; this is a great idea, but how will the output format be decided upon?</p>

<p>For instance, I have lots of uses for hCards in my applications, but the particular elements used and the order in which they occur vary considerably.  I might mark up a user profile with hCard on one page listing several profiles, each in its own row of a table, and then on another page listing just that one profile on its own, inside a <div>.  And then at the bottom of all of those pages I might have an <address> hCard listing contact information for the site owners.</p>

<p>In thinking about this, the decorator chains from Zend_Form came to my mind; could something similar be implemented here, allowing developers to specify their own templates without taking away whatever sensible defaults might otherwise be provided?</p>

<ac:macro ac:name="note"><ac:parameter ac:name="title">Zend Comments</ac:parameter><ac:rich-text-body>
<p>The Zend Framework team approves this proposal for immediate development in the<br />
extras incubator. We have the following notes and suggestions:</p>

<ul>
<li>Overloading of properties<br />
The examples show usage like thie following:
<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
$hcard->n->honorific-prefix = 'Mr';
]]></ac:plain-text-body></ac:macro>
which will result in parse errors, as PHP does not allow dashes in variable names. I suggest using Zend_Filter_Inflector to inflect camelCase to dash-separated internally. This will allow the component to follow ZF guidelines for variable naming, as well as retain the semantic link to the underlying specification.</li>
<li>Utilize iterators where reasonable<br />
A number of comments indicate that they would like results returned as an iterator. Our recommendation is to use iterators if they make sense to the design, but not require them out of necessity.</li>
<li>Aggregate data<br />
In the XFN proposal, he has a use case like the following when generating an XFN microformat:
<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
$xfn->relations = array('friend', 'met', 'neighbor');
]]></ac:plain-text-body></ac:macro>
We suggest that accessors for adding the relations would be useful:
<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
$xfn->addRelation('friend')
->addRelation('met')
->addRelation('neighbor');
$xfn->addRelation('friend')>addRelation('met')>addRelation('neighbor');
]]></ac:plain-text-body></ac:macro>
This would allow for programmatic creation of the format, and if similar accessors were created for retrieving, testing existence of, and removal of the relations, this could be even more powerful.</li>
<li>Use Accessors<br />
Most use cases show using public properties (either via overloading or direct use) to set and/or retrieve information. However, this does not allow for easy testing of existence, like the following:
<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
if ($hcard->hasNickname()) {
}
if ($hcard->hasNickname()) {
}
]]></ac:plain-text-body></ac:macro>
While I do not want to discourage using either overloading or public properties, accessors would allow for better control over the data provided (allowing normalization or error reporting), as well as for methods such as the above for testing existence of data.</li>
<li>View Helpers<br />
A view helper for generating microformat information to embed in the view should be considered part of the proposal.</li>
</ul>
</ac:rich-text-body></ac:macro>

<p>Paddy, status?</p>

<p>This would be really nice to have in ZF.</p>