Allow views templates to be more dynamic

@geertvd ok. I will look into how Migrate is doing it. As I said I have not checked it out so for all I know they are doing similar to what I am suggesting in item 3.

Either way it is worth looking into.

Ok here what's seems to be happening in Migrate

There is an abstract BuilderBase Plugin class that implements MigrateBuilderInterface.

form MigrateBuilderInterface docs

Builder plugins implement custom logic to generate migration entities from
migration templates. For example, a migration may need to be customized
based on data that's present in the source database; such customization is
implemented by builders.

I think our use is very similar, "migration entities" extend ConfigEntityBase just like Views. So just replace migration with View above and that is what we need.

So for example in Calendar instead of

a migration may need to be customized
* based on data that's present in the source database

We would need to customize Views based datetime property or field(which would include entity type, base table etc)

Ok. Here is the first try at. It is not complete but I wanted to get feedback on the idea.

Basically it makes a new ViewsBuilder Plugin class that other modules will extend to create a new View.

The plugins will have to be created programmatically via implementing ViewsBuilderPluginInterface::createView

I have created a test module views_templates_builder_test which creates a simple node view.

Eventually there will be test to that uses this module to test basically functionality.

Because views_templates_builder_test is under tests/modules it is hidden to turn it on you need to set
$settings['extension_discovery_scan_tests'] = TRUE;
In settings.local.php

How I see this working for an example the Calendar module is.

1. Create abstract class CalendarViewsBuilderBase
2. Create 2 classes that extend this class CalendarFeildViewsBuilder and CalendareBaseFieldViewsBuilder
3. Create 2 Plugin Derivative classes 1 for each in the classes in step 2
4. The Plugin derivative classes will create 1 plugin for each field or base field

Just want to make clear that #9 I get rid of the Views Template Config Entities. Since these were basically just loaded and then manually changed to Views they were more like cloning Views.

Alright added back Views Template Config Entities but they act slightly differently.

Ok I have added a new type of builder defined in ViewsDuplicateBuilderPluginInterface. Builder Plugins will extend ViewsDuplicateBuilderBase.

This type of builder will start with start with View Template and then edit it in the new method alterViewTemplateAfterCreation.

Any changes should be made to the template here. If there are no changes to the template it can be omitted in extended class.

I think Calendar builders should probably actually extend ViewsDuplicateBuilderBase

Ok I don't really like that fact that we are using config entities for Views Templates. I don't think they are config entities in any sense.

I have noticed some problems.

They get exported by CMI. There is probably no reason for this.
If this module doesn't delete the config entity there is problem when you try to re-install the module on the same site.

Basically they aren't used to configure anything on the site and I feel this is just using CMI just to load YML files which shouldn't be that hard.

Here is my idea

1. Modules that want to define Views Templates will create a folder called views_templates in the base of their directory.
2. This module creates a service called "views_template.loader"
3. ViewsDuplicateBuilderBase will use views_template.loader to load templates by looking in the current module "views_templates/[template_id].yml"

Thoughts, other ideas?

Alright right I think this is close to done!

I have removed the Views Templates as config entities because of the problems noted in #12

Now the Views Templates are just plain old yml files. This is actually what Migrate in Drupal 8 core is doing.

I created a new service views_templates.loader that simply loads a template from a yml for a plugin. Since it is service it should be easy change how it works if the plain yml files don't work well enough.

I have also a new method ViewsDuplicateBuilderBase::replaceTemplateKeyAndValues which will replaces values and keys in the template with values from the plugin definition. Derivative classes should be used so that Plugins have different replace values in the plugin definition.

@see ViewDuplicatorTest and it's corresponding yml file for an example of how this works.

Just some fixes to logic after using it with Calendar

Ok. I fixed this it. It will probably need to be revisited but it works for now.