Views filter by bean type

I have also ran into this problem. Surely this is simply an oversight?

I've experienced this too. I've so far worked around it by filtering against a field which is unique to the desired bean-type.

Not to be terribly terse here, but if you're trying to use Views to display Beans then "you're probably doing it wrong."

Just explaining why this issue may not have had the love you'd expect to see.

I totally agree that it should still work - but I could see why it would not be near the top of anyones list of priorities.

if you're trying to use Views to display Beans then "you're probably doing it wrong."

Haha, that's pithy, but, as a blanket statement, it's only true for certain limited values of "it".

Consider replacing "Beans" in that statement with the name of any other entity type. Is Views wrong for Beans but right for all the others? Regarding the idea of "using Views to display [[nodes, users, taxonomy terms]]": Sometimes it's right and sometimes it's not.

I for one have several very compelling use-cases for this. Yeah, it would be doing "it" wrong if all someone is trying to do is, display one bean on one page.

I'll concede that using a different entity-type to collect the same per-instance field-data, and using a View to display it in a block, is one alternative to using a View to select and render a fielded block-entity. Or that solutions like Context might suit some sites better than Views. But those would frankly be wrong ways, for at least some of the solutions I've built.

Hey guys,

This sounds like a very useful feature. Currently all views support is via the Entity API module. Since beans does not turn the bean types into entity's themselves, there is no integration out of the box.

Being that I dont' use views on my sites anymore (see http://treehouseagency.com/blog/neil-hastings/2011/09/06/building-energy...) this is probably something I won't do but I would like to see this feature in the bean module.

But as always Patches are welcome!

@hazah, yes, i would assume so.

Consider replacing "Beans" in that statement with the name of any other entity type.

Fair enough - like I said, this SHOULD work.

I've basically copied over the stuff from node, and used Entity API for the options. Seems to be working for me (although I just rebased on top of origin/7.x-1.x so please test).

@hazah I pinged someone on #drupal-contribute thinking I was pinging you, irc nickname is Haza`

Anyway, you should just publish your ongoing work as work-in-progress patches. I didn't want to write this from scratch, but I needed it so...

Still looking for more testers on this.

hazah, can you test it?

Tested and this works perfect.
I can add a 'bean type' filter, and expose it.

Great job! http://drupal.org/commitlog/commit/22232/fb86d1c750c626be875bdc72d8f02e5...

@indytechcook Can you start using git am to give me attribution for my patches? I already use git format-patch to make your life easier...

barraponto, i do give you author attribution for all of your patches using --author. dreditor gives me some short cuts for creating the commit messages which give you full credit for the commit.

Sorry, i thought you weren't attributing since you seem not to use git am.
Thanks a lot :D

Ive been setting up a site that exports beans using an export view and I needed to have the bean type column available as both an argument and a field, so Ive created a simple patch that adds these additional handlers. Not sure how beneficial this is to others, but thought Id share the patch anyway.

Updating the above patch to apply against 7.x-1.1. Now just adds argument handler for 'type'.