Architecture question

[zyuhel]

There is Oembed provider available in code. But some resources provide oembed data without normal acknowledgement.(Yes it is incorrect according oembed spec, but we live in real world, for example in 500px for url https://500px.com/photo/126454999/fox-by-helena-kuchynková we can find oembed at https://500px.com/photo/126454999/oembed.json ) So we could make url for oembed data. But current oembed provider class need endpoint. We can't set endpoint to url, because we has now acknowledge of it. We don't want it global.
The good solution will be to check returning headers, so that if we get json from server it is content to use, not to search for oembed endpoint. But current HTTP class doesn't provide any headers info, it just returns plain text.
The less painful solution to current architecture is to add some internal flas as (requesting url is endpoint) and then in specific resource provider set it, and preprocess url as needed. But here there will be other problem, because url can be not returned in requested json, it will be set as requested one, that will be incorrect one, cause lead not to source page, but to processed one.
Maybe the best solution will be just write my own provider class for such "incorrect oembeds", but it will almost fully be the same. May be i should add above flag and even requesting url to options page. but in providers setup i couldn't get requested url, to modify it.

For some resources we need to chain calling different providers, like oembed and metatags, and so it is again look pretty strange, don't know how will be more right way to use it.

So may be you could suggest what would be good according existent architecture.

[zyuhel]

Also the question about extending providers list.
According to docs

$Essence = new Essence\Essence([
    // the SoundCloud provider is an OEmbed provider with a specific endpoint
    'SoundCloud' => Essence\Di\Container::unique(function($C) {
        return $C->get('OEmbedProvider')->setEndpoint(
            'http://soundcloud.com/oembed?format=json&url=:url'
        );
    }),

    'filters' => [
        // the SoundCloud provider will be used for URLs that matches this pattern
        'SoundCloud' => '~soundcloud\.com/[a-zA-Z0-9-_]+/[a-zA-Z0-9-]+~i'
    ]
]);

Of course in reality we will need to add providers to Container using ->configure, so it will be good to reflect this in documentation.

May be the should be easier way to add providers? so that anyone could make their provider in different repo and it could easily be loaded. If providers will continue adding to list it will became not so maintainable or easy to read imo. May be we need provider interface so that it could instantiate filters, providers list, and internal object itself. So we could just pass additional providers to constructor.

[felixgirault]

I'm sorry I didn't quite understand your first comment. Do you have a use case or a little piece of code to show me?

About the providers list, I'm quite satisfied with the way they are initialized now.
In the first version of essence, providers were in fact classes, but it was also really annoying to handle, as it required a lot of almost empty files.
Another good point with the way it works now is that filters are totally decoupled from providers.

Do you think a provider interface would be easier to use? I think a simple bootstrap file can already be used quite simply and committed in a separate repo.

[zyuhel]

About first comment.
I got provider, for example 500px, it make some data available as oembed, some as opengraph, and some as twittercards ( in fact twitter card values could be thrown away), together with some own tags.

$this->configure([
            '500PXMetaPattern' => '~^(og|five_hundred_pixels):~i',
            '500PXDefaults'=> [
                'providerName'=>'500px',
                'providerUrl'=>'https://500px.com',
                'type'=>'photo',
            ],
            '500PXMapping' => [

                'og:title' => 'title',
                'og:description' => 'description',
                'og:image' => 'thumbnailUrl',
                'og:image:url' => 'thumbnailUrl',
                'og:image:width' => 'width',
                'og:image:height' => 'height',
                'og:video:width' => 'width',
                'og:video:height' => 'height',
                'og:url' => 'url',

                'five_hundred_pixels:author'=>'authorUrl'
            ],  

            '500PXPreparators' => [],
            '500PXPresenters' => Container::unique(function($C) {
                return [
                    $C->get('500PXReindexer'),
                    $C->get('500PXCompleter')


                ];
            }),


            '500PXCompleter'=> Container::unique(function($C) {
                return new Completer($C->get('500PXDefaults'));
            }),
            '500PXReindexer' => Container::unique(function($C) {
                return new Reindexer($C->get('500PXMapping'));
            }),
            '500PXProvider' => function($C) {
                $OpenGraph = new MetaTags($C->get('Http'), $C->get('Dom'));
                $OpenGraph->setPreparators($C->get('500PXPreparators'));
                $OpenGraph->setPresenters($C->get('500PXPresenters'));
                $OpenGraph->setMetaPattern($C->get('500PXMetaPattern'));

                return $OpenGraph;
            }
        ]);

so this will be the partial solution for opengraph/own tags. But raw author name available only in oembed data. located not as oembed spec suggests.

So the question how could i get it. It seems that i couldn't use oembed provider because url building is tightly binded in it.
everything in oembed is applicable, except forming endpoint.
clone all code just to change endpoint location seems pretty awkward. So how can i modify endpoint url? It need to be modifed according the requesting url. so if it was possible to user preparators to form endpoint url, that will be a pretty nice solution.
can current url be accessed inside container?

[felixgirault]

Oh ok!

I'm currently fiddling with a JS rewrite, with a different philosophy, and I am trying to resolve the same kind of issues.
I would like to make preparators/providers/presenters really composable, separating concerns more clearly between data fetching, extraction of data etc, and then pipe them together in any way we want.

I think a kind of middleware implementation would work well, or a pattern with Request/Response objects, like a lot of frameworks.

I'll continue working on this to see if it leads somewhere.

[zyuhel]

About the js rewrite. iframe.ly have js sources, with many providers, so you could take at look at them.

current api lacks normal http firmware layer. it use http client just as file_get_contents :)
maybe providers should work with http response instead of html text. :)