New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Question: Why aren't field options available to templates? #612
Comments
You can use it in your subclass, for example I have a subclass that has the following public method (so I can then use it in views)
|
@ThisIsMissEm Just checking in on this... Was @j-dexx's code snippet useful to you for solving your problem? I agree with the approach-- you can create subclasses of fields and expose public methods to use in your views. Does that approach work for you? If not, what kind of behavior would you like to see? If you could illustrate with an example (pseudocode is fine) that would be helpful. Let us know, thanks! |
@carlosramireziii I guess I could do it with subclasses, but then it's a question of batteries included or bring your own batteries Is there any negative side effect of exposing all the options to the View templates? |
Also raised at #1202 |
…1513) Over at #612, a fair point was made: if field `options` were public, they could be accessed from templates. This would enable users to customize fields without having to create new field types, which I find a bit more cumbersome. An argument against this change would be that it increases the contact surface of field types, which can be an issue later if we change the interface of fields. An argument for this change would be that the interface of fields is unlikely to change radically at this point. If it did, probably subclasses would have to change anyway too, possibly forcing more significant changes than that of how to access the options.
Fixed by #1513 |
…1513) Over at thoughtbot/administrate#612, a fair point was made: if field `options` were public, they could be accessed from templates. This would enable users to customize fields without having to create new field types, which I find a bit more cumbersome. An argument against this change would be that it increases the contact surface of field types, which can be an issue later if we change the interface of fields. An argument for this change would be that the interface of fields is unlikely to change radically at this point. If it did, probably subclasses would have to change anyway too, possibly forcing more significant changes than that of how to access the options.
In https://github.com/thoughtbot/administrate/blob/master/lib/administrate/field/base.rb#L46
options
is marked as protected, which seems to mean that from customised views, I couldn't make use of the options.My use case was to add an option to
BelongsTo
and customise the views as to allow sometimes not having aBelongsTo
as a link (we have some cases where we don't actually want an admin panel for certain resources, butBelongsTo
expects there to be one).For now I've just worked around this by creating a
TextualBelongsTo
which subclasses fromBelongsTo
and just changes the templates a bit. It seems to be nicer to actually just be able to specify arbitrary options and then just customise the views, rather than subclassing.The text was updated successfully, but these errors were encountered: