Current Issues

We are having 4 issues with the current Extractors mechanism:

1. The order in which they should be executed (create order/position property on extractors #107)
2. SeoMetadata should inherit (create a helper to get the SeoMetadata decisions from child nodes #87)
3. There should be a way to turn on/off extractors per document (do not enable title guesser by default for all #125)
4. Some caching is needed for the extractors ([1.1] AnnotationExtractor and switching to JmsMetadata #118 (comment))

(1) and (3) are especially pretty hard to solve using the extractors.

I think we should go in a complete new direction for 1.1, however that can make things more complicated. I don't know if that's really welcome, since this bundle is pretty nice because it's not complicated.

Using Mappings

My idea was to use mappings instead of extractors. Instead of implementing some interfaces and introducing some wrapper methods which just call other functions, we should have a way to "map" some values of the document to SeoMetadata.

This can be done using the JmsSerializer. Some examples:

use Symfony\Cmf\Bundle\SeoBundle\Annotation as Seo;

class Page
{
    /**
     * @Seo\Title
     */
    protected $name;

    /**
     * @Seo\MetaKeywords({
     *     "strategy": "append"
     * })
     */
    protected $tags = array();

    /**
     * @Seo\MetaDescription(
     *     "stategy": "override"
     * })
     */
    protected $description;
}

Of course, we should also support Yaml and Xml mappings and mappings for methods. For instance:

Acme\BlogBundle\Document\Article:
    properties:
        title:
            title: ~
        tags:
            meta_keywords: { strategy: append }
        description:
            meta_description: { strategy: override }

<seo-mapping class="Acme\BlogBundle\Document\Article">
    <property name="title">
        <seo type="title" />
    </property>

    <property name="tags">
        <seo type="meta_keywords">
            <option name="strategy">append</option>
        </seo>
    </property>

    <property name="description">
        <seo type="meta_description">
            <option name="strategy">override</option>
        </seo>
    </property>
</seo-mapping>

Support Custom Data

Then we can also fix #131 by using a generic "Meta" mapping for custom meta values:

// ...
class Page
{
    /**
     * @Seo\Title
     * @Seo\Meta("og:title")
     */
    protected $name;
}

Acme\BlogBundle\Document\Article:
    properties:
        name:
            title: ~
            meta: { name: og:title }

Keeping BC

Of course, we should be BC. So we should keep supporting the extractors, but deprecate it.
replaces #118