Administrate: Dynamic select field

[bekicot]

• What would you like to be able to do? Can you provide some examples?
  This should be the simpler case

Field::Select.with_options(collection: [Time.current])

another case is if we want to keep the list up to date. e.g via database record

• How could we go about implementing that?
  I think by adding another parameter type, it should be something like lambda would be enough to solve the problem.

• Can you think of other approaches to the problem?
  No other approach. as to my knowledge.

[pablobm]

A way to do this would be to implement a new field type, probably inheriting from Administrate::Field::Select, like this:

# /lib/administrate/field/relative_day_select.rb
module Administrate
  module Field
    class RelativeDaySelect < Field::Select
      def selectable_options
        [
          ["Today", Date.today],
          ["Tomorrow", Date.tomorrow],
        ]
      end
    end
  end
end

# /app/views/fields/relative_day_select/_form.html.erb 
<div class="field-unit__label">
  <%= f.label field.attribute %>
</div>
<div class="field-unit__field">
  <%= f.select(
    field.attribute,
    options_from_collection_for_select(
      field.selectable_options,
      :second,
      :first,
      field.data.presence,
    )
  ) %>
</div>

# /app/views/fields/relative_day_select/_show.html.erb 
<%= field.data %>

# /app/views/fields/relative_day_select/_index.html.erb 
<%= field.data %>

Does that help?

[bekicot]

@pablobm That would help a lot. But just wondering, does this feature request shall be implemented in the select field instead? I think it is okay to add an option for the user to choose whether they want constant select options or dynamic select options. The drawback I could think of is a little bit of performance degradation on checking whether the expected option is a lambda or not. And probably some maintenance effort 😄

If you think it is okay to add such functionality, I can make a pr for it. After working on #1517

[pablobm]

I think it's ok. I don't think it would cause any performance degradation.

Ideally, I think a solution should be inspired by Rails's options_from_collection_for_select, to minimise maintenance effort as well as avoid introducing new conventions. What do you think?

[pablobm]

To clarify: try a PR and I'll have a look.

[nickcharlton]

@bekicot, were you able to open a PR for this?

[sedubois]

NB: ActionView's collection_select already accepts a proc. Administrate does not have this field type so I had to build my own Administrate::Field::CollectionSelect starting off from this one which is outdated. So even with this PR improvement I need to keep using my custom one in order to be able to use Selectize and support multiple.

From the ActionView::Helpers::FormOptionsHelper#collection_select documentation:

The :value_method and :text_method parameters are methods to be called on each member of +collection+. The return values are used as the +value+ attribute and contents of each tag, respectively. They can also be any object that responds to +call+, such as a +proc+, that will be called for each member of the +collection+ to retrieve the value/text.

This might illustrate that the separation between "core" and "external" Administrate code is not so straightforward:

• people can create their own plugins and share them on the list of plugins wiki page, but that information tends to be outdated or not verified and so the quality information gets diluted;
• external plugins might not be as stable as Administrate itself, because people are basically on their own and e.g. cannot ask for their PRs to be reviewed by other Administrate users (and the wiki page itself is not subject to a review process), and conversely the maintainer him/herself might not be available any more (as my example above shows);
• various users (such as myself) might have functional custom administrate fields in their own private systems but have no clue how to turn that into a gem (although I'm not a good example because I could just have forked the outdated one; but then what should I put on the wiki page? Keep the outdated one, replace with my own, keep both?);
• even if one finds an external plugin that is functional, it does not benefit from a clear API documentation like the "official" API documentation;
• the documentation of these external plugins is fragmented (not available from the same central place);
• we might also end up in situations where an external plugin already addresses a need, but due to lack of visibility then we partially try to address the need internally (as in this PR), which defeats a bit the purpose of supporting external plugins.

I don't know what is the solution. Maybe the documentation system could integrate external plugins as well...

[nickcharlton]

@sedubois, could you open a new issue for that so we can keep track of it?

[sedubois]

@nickcharlton sure, but as I mentioned quite a few things could you say which part you think constitutes the issue that I should create? Do you mean that we should add a support for collection_select or are you referring to my other ramblings?

[bekicot]

@sedubois I agree that we should have some kind written convention. I also agree that we should have a defined scope of what what the administrate trying to achieve and let plugins to solve other problem, that is not defined in the scope.

However, don't you think this is not relevant to this issue? Since you are the first one that made the point and found out that it is useful to have such a documentation system, it would be best for you to open a new issue for that. And discuss further in the newly created issue.

We may have a written 1.0 milestone that is usefull for us.

[sedubois]

@bekicot yes let's create a new issue, will just wait for @nickcharlton's feedback to see what its scope should be.

[nickcharlton]

I think you should open a new issue for collection_select (it's in ActiveView, perhaps core should support everything that does?).

I'm going to pull your other comments and open couple of documentation issues, as this is something I want to focus on and it provides a good starting place. Thanks!