Remove local options from essence editors

[tvdeyen]

What is this pull request for?

Why? Passing around options hashes from the element editor views into the essence editor views and even in the params is error prone and not necessary in most of the time. We already have the settings key on the contents definition in the elements.yml.

Notable changes

This removes the local options and html_options hashes passed to the essence editor partials. Stop passing local options from all element editor partials into essence editors.

Please set all options you have passed into the essence editor on the content definition itself.

Example

<%= element_editor_for(element) do |el| %>
  <%= el.edit :image, size: '2000x800', crop: true %>
<% end %>

will become

- name: hero
  contents:
    - name: image
      type: EssencePicture
      settings:
        size: 2000x800
        crop: true

Q: But what about dynamic options?

Sometimes you want to pass dynamic instead of static options into the essence editor. Like for a selection of pages you want to let chose an editor from.

A: Create an essence for this

Using an essence for multiple purposes is often not the best way of implementing those use cases. Imagine a event select for instance.

Instead of storing the Event#id in a string column of the EssenceText or EssenceSelect you should add your own custom essence (say EssenceEvent) and add a event_id foreign key and set the event as ingredient_column.

Another good example is the Alchemy Solidus extension. It provides EssenceSpreeProduct and EssenceSpreeTaxon essences to work with.

This is a much more reliable approach of using dynamic values in your Alchemy instance.

B: Use EssencePage to reference pages

If you want to reference a page you can use the newly introduced EssencePage.

[mamhoff]

Yay for the simplification, this is great I think. However, I believe a deprecation warning makes sense if the functionality is still there but to be removed in the future. As we're removing the functionality in this PR, I think it's more appropriate to raise instead.

[tvdeyen]

@mamhoff #1642 adds deprecations

[mtomov]

Yeah, absolutely for - have never used that.