Make repository URL backends pluggable

After analysing it and talking with @jpetso, we found that pluggable url backends do not have enough reasons to be.

So at oop branch the idea of url backends dissappear.

In the other side, the functionality mentioned here is a helper, and it can be done with form alter, so it would be handy to have at least one as a reference implementation.

related to #156118: Automatically generate the value of 'Link to webcvs/viewcvs' field for a project

Marking this as postponed, since IMHO this will be happening as part of converting VersioncontrolRepositoryUrlHandler into several ctools plugins \o/ #976148: Recover links to VCS web viewers and issue tracker at views

Ok, I am moving the title back to the original, since the idea of making them pluggable come up again.

The main difference will be the approach, as mentioned in #4, but postponing this until the first ctools patch gets in: probably #979040: Make pluggable the process of mapping of raw vcs data to Drupal users

reopening, since #979040: Make pluggable the process of mapping of raw vcs data to Drupal users is committed

have an uncompleted patch, going to post it here soon.

untagging as decided today on meeting

Tagging for Git Sprint 8
Connects to the repo viewer ... #939024: Decide if we should switch to a homemade git viewer instead of cgit or gitweb

Here is a patch with the general idea, it still needs some work, but uploading it since I will not be working on it for a day.

Sorry my review of this got delayed.

• There's a VersioncontrolRepository::$pluginInstances property that should probably be where the instantiated viewer object gets stored, for consistency with the way other plugins operate.
• Let's move VersioncontrolRepositoryUrlHandler into its own inc file somewhere in a way more consistent with how other comparable classes are handled.
• I don't really like mixing in links to the commitlog here, it situates these plugins in a position awkwardly halfway between encapsulating a separate repo-browsing application entirely and log viewer functionality, which (as part of VCAPI core) has other ways to be switched around. I'd prefer to simply get rid of any methods that deal with the commit log. I guess that basically means linking to a tree browser, an individual file view, and maybe a diff view.
• There are some var_dump()s and dpm()s in the views handler.
• If we want to keep consistent with the interface we've been using in the repo edit form, then we may need to add in some ctools modals to manage additional configuration of the url viewer plugins. Maybe. Depends on how much conf they need, versus how much is just hard-coded into the plugin.

So apart from wanting to decouple the commitlog from the repo browser in this plugin, looks like we're pretty well on the same page. Let's see some more patches :)

Ok, I think this is ready.

What is new in this patch:

• hook_update_N() to update $repository->data['versioncontrol'].
  • Remove url_handler object.
  • Add base_url string.
• Move webviewer_url_handlers plugin documentation to an empty plugin.
• Remove tracker url from url handler templates.

It is going to be re-added as a views handler option for operation
messages.

• Add vcs to filter webviewers by vcs.
• Add %repo_name placeholder for URL templates at URL handler plugins.
• Use $repo->pluginInstances data member to store instantiated object for webviewer.
• Move VersioncontrolRepositoryUrlHandler into its own inc file.
• Add directory_log_view URL template for URL handlers

I'll try to get to this a little later tonight, very focused on the beanstalkd stuff atm.

I noticed some mistakes while implementing integration on views handlers, so here the fixes.

 +      if (!class_exists($class_name)) {
 +        throw new Exception("Plugin 'webviewer_url_handler' of type 'webviewer_url_handlers' does not contain a valid class name in handler slot 'handler'", E_WARNING);
 +        return FALSE;
 +      }

There's static text that should be variable in those error messages.

 +    unset($data['versioncontrol']['url_handler']);
 +    $data['versioncontrol']['base_url'] = '';
 +    $data = serialize($row->data);

I don't like the namespacing within the $data array, never did (sign of bad architecture, IMO). Let's not introduce any more of it.

The gitweb inc is still in there, and...

 @@ -149,9 +149,14 @@ abstract class VersioncontrolTestCase extends DrupalWebTestCase {
        'auth_handler' => 'ffa',
        'author_mapper' => 'simple_mail',
        'committer_mapper' => 'simple_mail',
 +      //FIXME use a general commitlog url handler
 +      'webviewer_url_handler' => 'gitweb',
      );

...still referenced in the views handler.

I must admit, I'd never quite thought to do what you've done with the 'none' plugin for this - use variables statically declared as part of the plugin as args to the plugin's class. Kinda awkward, but OK for us to start with, anyway.

Apart from that stuff, looking pretty good. Fix it up and I think we're RTBC, though we'll need a follow-up issue to do the gitweb plugin in vc_git.

Ok, here the changes mentioned on #15.

OK great. Go ahead and commit.

I changed some things before committing:

• Add main repository view to URL templates, to make possible #156118: Automatically generate the value of 'Link to webcvs/viewcvs' field for a project
• Remove gitweb url handler for versioncontrol in favour of adding it at git backend.
• minor nitpicks: Remove not existing file from info file and change docs at none.inc

Ok, it's in!