- Sponsor
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Generate SHOW_PAGE_ATTRIBUTES
as an explicit array
#130
Comments
hm... I originally moved away from a similar solution, with That was in #111. What do you think? I do like how this solution has a single place to change the order, but I'm not sure if it'll make things difficult for new users. |
Two points about that:
|
@mcmire I agree about the hash. All of the constants in that file are required by Administrate, so yes - I think I'd prefer to spell out It would be up to the user to abstract duplication where it makes sense. Thoughts? |
I think that's fine. I think that the attributes are going to end up getting customized anyway and in order to do so it's best to have it as an array. |
SHOW_PAGE_ATTRIBUTES
as an explicit array
Closes #130 Problem: The dashboard generator specifies: ```ruby SHOW_PAGE_ATTRIBUTES = ATTRIBUTE_TYPES.keys ``` This means that the order of the show page attributes is dependent on the order of keys in the `ATTRIBUTE_TYPES` hash. Ruby hashes happen to be ordered, but we shouldn't make an assumption that hashes are ordered because that is not a property that hashes are designed to have. Solution: Because we assume that users will be editing `SHOW_PAGE_ATTRIBUTES` to customize the contents and order of show page attributes, we'll generate an explicit array for them to modify.
Closes #130 Problem: The dashboard generator specifies: ```ruby SHOW_PAGE_ATTRIBUTES = ATTRIBUTE_TYPES.keys ``` This means that the order of the show page attributes is dependent on the order of keys in the `ATTRIBUTE_TYPES` hash. Ruby hashes happen to be ordered, but we shouldn't make an assumption that hashes are ordered because that is not a property that hashes are designed to have. Solution: Because we assume that users will be editing `SHOW_PAGE_ATTRIBUTES` to customize the contents and order of show page attributes, we'll generate an explicit array for them to modify.
Right now,
COLLECTION_ATTRIBUTES
,SHOW_PAGE_ATTRIBUTES
, andFORM_ATTRIBUTES
useATTRIBUTE_TYPES.keys
as a base set of attributes. It would follow, then, that in order to re-order fields that appear in a form or table, you re-order the keys inATTRIBUTE_TYPES
. However, this seems a little odd, becauseATTRIBUTE_TYPES
is a hash, and so the order of its keys should be irrelevant. (It just so happens that hashes in Ruby are now ordered, but they really shouldn't be, and we shouldn't be assuming they are.)So here's a suggestion: introduce a
BASE_ATTRIBUTES
constant that all of the other*_ATTRIBUTES
constants use. The dashboard generator would have to set this to an explicit array based on the columns the model has, but then we'd encourage people to modify this array instead ofATTRIBUTE_TYPES
. While we're at it, it might be useful to placeATTRIBUTE_TYPES
first.So a dashboard class would look like this:
The text was updated successfully, but these errors were encountered: