[TYPO3-core] RFC: #15699: Provide a wizard for media to process the video url

[Ernesto Baschny [cron IT]]

Helmut Hummel schrieb am 13.09.2010 23:22:
> Hi,
> 
> On 13.09.10 19:16, Steffen Kamper wrote:
>> Ah, sorry. We removed mtv as they changed their way delivering videos, 
>> so i forgot to remove it from the provider list.
> 
> This proves my first feeling, that the process_<providername> methods
> are quite hardcoded, which doesn't reflect the fact that the HTML on
> these sites is subject to change. So we probably also need to be able to
> change/ configure the parsing of the url, not only to add additional
> providers.
> 
> I also do not like the mix of concerns in the mediaWizard class. While
> on one hand beeing a kind of manager or dispatcher selecting the right
> provider, it also carries some providers.
> 
> In my eyes it would be cleaner to speperate these concerns into a
> manager/dispatcher class and different provider classes. Then we could
> have a provider interface requiring the method "processMediaUrl" and get
> rid of this "magic" process_foobar function names.
> 
> That said, we should think of either delivering only a few providers and
> add more in a extension delivered from TER or at least have the
> possibility to override providers by such an extension.
> 
> I can offer an updated patch taking my comments into account, but first
> I want to hear from you if it is worth the hassle. I do not insist in
> doing it this way, just wanted to comment what I think about it.

I haven't looked deeply in the matter, but I have a similar feeling as
Helmut. We need an nice PHP interface which a media provider should
implement (maybe just containing "processUrl(...)") and a manager which
is responsible for collecting "registrations" and dispatching the
correct implementation for a certain mediaprovider.

The "sample providers" would be extensions that we release on TER and
which could be updated more often and more independently of TYPO3
releases. The core shouldn't have hardcoded stuff that can outdate any time.

We are having a very similar task for our FORM Api (extensions
registering its services with a manager and other extensions or the core
fetching available service-providers from the manager). So to me this
sounds like "services", but we would like to have a "modern services
API" (the old school "services" API is.. well.. old school).

I have discussed this in the core team already, but we should discuss it
in the -dev or -v4 lists too.

I'll come up with something tomorrow or the day after that.

Cheers,
Ernesto