Skip to content
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

Closed
ThisIsMissEm opened this issue Jun 16, 2016 · 5 comments
Closed

Question: Why aren't field options available to templates? #612

ThisIsMissEm opened this issue Jun 16, 2016 · 5 comments
Labels
feature new functionality that’s not yet implemented fields new fields, displaying and editing data

Comments

@ThisIsMissEm
Copy link
Contributor

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 a BelongsTo as a link (we have some cases where we don't actually want an admin panel for certain resources, but BelongsTo expects there to be one).

For now I've just worked around this by creating a TextualBelongsTo which subclasses from BelongsTo 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.

@j-dexx
Copy link

j-dexx commented Sep 30, 2016

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)

def thumbnail                                                  
  options.fetch(:thumbnail, false)                       
end 

@carlosramireziii
Copy link
Collaborator

@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!

@ThisIsMissEm
Copy link
Contributor Author

@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?

@pablobm
Copy link
Collaborator

pablobm commented Jan 1, 2020

Also raised at #1202

@nickcharlton nickcharlton added feature new functionality that’s not yet implemented fields new fields, displaying and editing data and removed has feedback labels Jan 2, 2020
pablobm added a commit that referenced this issue Feb 13, 2020
…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.
@pablobm
Copy link
Collaborator

pablobm commented Feb 13, 2020

Fixed by #1513

@pablobm pablobm closed this as completed Feb 13, 2020
KingTiger001 added a commit to KingTiger001/admin-Rails-project that referenced this issue Jan 15, 2023
…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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature new functionality that’s not yet implemented fields new fields, displaying and editing data
Projects
None yet
Development

No branches or pull requests

5 participants