Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
The admin bean/block list is hardcoded.
It could be easily switched to a view, if all relevant handlers are provided.
Having it in views would lead to great editor experience as the lists can be easily customized.
Comment | File | Size | Author |
---|---|---|---|
#32 | bean-overview_as_view-1906958-32.patch | 10.89 KB | Albert Volkman |
#27 | bean-overview_as_view-1906958-27.patch | 1.17 KB | Albert Volkman |
#27 | interdiff.txt | 608 bytes | Albert Volkman |
#22 | bean-overview_as_view-1906958-22.patch | 10.89 KB | ytsurk |
#19 | bean-overview_as_view-1906958-19.patch | 12.26 KB | ytsurk |
Comments
Comment #1
indytechcook CreditAttribution: indytechcook commentedWhile I try not to use views on my projects, I do accept patches for enhanced functionality as long as it doesn't degrade the current experience or goals of the project.
Comment #2
miro_dietikerWe might provide.
Note that in our case, we see the admin view of beans is very limited.
You can't search for bean titles in a "contains" exposed field.
The order of the list is currently not satisfyingly defined.
(We end um with a paginating list of unordered beans where you never know how to find the right one...)
Also now views is in core for D8, so it's the right direction...
Comment #3
ytsurkthere we go.
already using the handler from #1918188: Few useful views handlers for work with bean blocks
on the overview page, the view is only triggered when views module is enabled.
Comment #4
BerdirShould have a @file on the first line of the docblock.
No idea why the default view has tabs on most lines but not all?
Comment is wrong.
Comment #5
BerdirInstead of this, views could also simply override the path, it does define everything in hook_menu_alter() for that.
Comment #6
ytsurk@berdir, thx for the feedback.
sorry for the formatting issues ....
so you would implement the bean_menu_alter method, and if views is there, override the path to show the view - right ?
Comment #7
miro_dietikerTrailing spaces
"operation links" ... It's contextual links output, not a typical static "Edit" link as e.g. common on the admin/content list.
Tabs and a lot more tabs in later lines.
Is the naming "operations" common for such a handler?
I see it's about contextual links.. Finally you check for edit permissions and trigger all contextual links?
again, contextual / operations ... after form submission.
Trailing spaces
"operation links" ... It's contextual links output, not a typical static "Edit" link as e.g. common on the admin/content list.
Tabs and a lot more tabs in later lines.
Is the naming "operations" common for such a handler?
I see it's about contextual links.. Finally you check for edit permissions (only) and trigger all contextual links? Do we even need that edit check?
Comment #8
ytsurkthe operations handler comes form commerce, so the wording should be fine.
i can change it to contextual links ... ?!
regarding permissions, i would say edit should stay.
menu_contextual_links does not check for permissions as far as I see
edit somehow indicates to me,
that operations are allowed, even thoe modules hooking in there could have own permissions (fe. translate link ..)
Comment #9
BerdirViews should by default override the custom page callback if you specify the same path.
Comment #10
ytsurkwhen adding via view display (overriding the path),
this part gets lost
so - i will keep the old approach.
Comment #11
BerdirYou should be able to specify that it has a local task menu?
Comment #12
ytsurkso I have to hook_menu_alter .. ?
http://drupal.org/node/1126762
EDIT: just making the menu entry for the view page is enough.
Comment #13
ytsurkbetter like this
Comment #14
BerdirCode looks good now.
Test that If you have views, then the view is automatically displayed on admin/content/blocks but you can also disable it manually if you don't want that.
About the view itself, I think we don't need bid as a column in there. And if you, in the table options, display the delete link in the operations column then that additional column and the space between the links goes away. And maybe expose an additional search field for the description? sometimes you might know the description of a block you're looking for, not the title. Unfortunately, it is AFAIK not yet possible to search in two different fields with a single exposed filter without an additional module.
Comment #15
ytsurkthis is already tested. so the view shows as soon as views module is enabled. the view can be omitted via views UI and disabling it ..
think this is kind of the default behavoir.
i'll move the delete link to the operations / contextual links colums, bid sometimes can be useful.
i also give the second exposed filter a try - if an additional module is needed, i think we should limit to one !
Comment #16
BerdirI know it works, what's what I meant to say with that, that I did test it.
don't think the bid is important here, you're only interested in the machine name/delta. Having two exposed filters is easy. Having a single exposed filter that does a search in two different columns is not.
Comment #17
ytsurkalright,
rearranged the view a bit:
Comment #18
BerdirWhy uppercase?
Looks good otherwise, still disagree with showing the bid column but that's something for the maintainer to decide.
Attaching a screenshot of how this currently looks.
Comment #19
ytsurkalright - convinced .. : bid is removed ;)
also the VIEW joke is removed
Comment #20
BerdirLooks good to me, time for a review from the maintainer :)
Comment #21
miro_dietikerI guess these remember_roles are environment specific... Dunno how this should look like for a generic install.
API documentation of remember_roles in exposed_form.
Comment #22
ytsurkMiro, you're right. thx for again taking a look !
i copied infos from my local setup into the view.
Comment #23
miro_dietikerNow looks fine!
Comment #24
DamienMcKennaShouldn't this also either remove the existing 'admin/content/blocks' page or have the default view disabled so it has to be specifically enabled?
Comment #25
BerdirNot necessary. If views is disabled, then it uses the default implementation (The maintainer doesn't want to depend on Views, see above) and if it's enabled, then the view is used automatically.
Comment #26
indytechcook CreditAttribution: indytechcook commentedThis is a similar approach that admin_views, and several other modules use.
I'd prefer this be set to TRUE so it's a passive change.
Comment #27
Albert Volkman CreditAttribution: Albert Volkman commentedDone.
Comment #28
BerdirLooks good, disabled by default is also fine with me.
Comment #29
ytsurkYes - i can agree too.
Comment #30
miro_dietikerGreat, ready then.
Comment #31
miro_dietikerI just have realized that the patch of Albert Volkman is missing the new files introduced by ytsurk.
Comment #32
Albert Volkman CreditAttribution: Albert Volkman commentedD'oh. Thanks for the catch @miro_dietiker!
Comment #33
fmitchell CreditAttribution: fmitchell commentedAssigning to me to bring in
Comment #34
miro_dietikerFrom discussion with maintainers:
We should add a hint about new views integration to README.txt and how to enable.
Comment #35
fmitchell CreditAttribution: fmitchell commentedDone and committed:
http://drupalcode.org/project/bean.git/commit/b919788
http://drupalcode.org/project/bean.git/commit/2ddab7c
Comment #36
DamienMcKennaThanks for everyone's work on this.
BTW it's customary to leave the issue in 'fixed' status after the commit.