Views integration

That is possible certainly, although I know nothing about it. Whether it happens depends on whether I have time and motivation, which is unlikely within the next few weeks at least, or whether someone else writes a patch.

Can I ask your use case though? The chances are fairly good you could accomplish exactly you're trying to do in under 10 lines of PHP.

Okay, well there's a good chance I'll get to this before that, I've been meaning to learn the Views API for awhile now but I've put it off because I've had no actual reason to do it and there are 2 API's now (Views 1 for 5.x and Views 2 for 6.x). Of course this could only work for 6.x because Views 1 has no user connection...

I tried to do this today and couldn't get it working. That's about all the time I have to spend on it so I probably won't be doing this. I'm not going to mark as "won't fix" because it's possible that one day I'll completely rewrite this module for a 6.x-2.x, in which case this will definitely go in... but that won't happen until my social networking sites are upgraded to 6.x, which won't happen for quite some time.

We're officially on 6.x-2.x now, so I'm re-opening this one. It's one of the few remaining things I need to complete before I will create an official release. It should also take care of integration with FriendList and Flag Friend.

I still really have no idea how to do this. I'll figure it out eventually if no one steps up to help, but of course it would be great if someone could either review integration that I write that doesn't work or go ahead and write it for me. :)

Hi All,

I needed this functionality today for a site I'm working on. I've written the code for creating a new View Style based on the 2.x-dev code. I've attached the patch for this.

I fought for a while with getting most recent status update on users for when doing a node or user view but ran out of time to work on this.. I spoke with merlinofchaos on IRC and the basic recommendation is to use a custom views_field_handler which implements a pre_render hook to run a sub query. As I said, I messed with this and ran out of time on it for now but may come back to it at some point.

Anyway, this patch makes a step in the right direction and provides the new View Type to list status updates and you can use UID as an argument, so you can do a listing of a single user's updates or you can do a listing of all status updates on the site (which was the functionality I needed at the moment.)

Oh yeah, and this patch is on the 2.x-dev version and will not at this time work on the 1.x due to the schema change, though if it needed to be back ported to 1.x it's just a one line change.

Cool, sounds like a good start. I definitely would like to move towards getting Views to work with a user view too because that's where we can get integration with modules like FriendList and Flag Friend. Thanks for taking a look at all this.

One other option that came up was to create a new table which just stores the most recent status update from users. It would make creating the view easier and would actually be a performance boost because you're not having to run a sub query all the time in order to grab the most recent one. The table could even be a simple uid, sid table which overwrites each uid, sid pair when a new update comes in, then you can join the tables to get the actual status.

It's either that or a subquery in the views handlers.

It seems to me that the question there is whether it would be slower to run an extra database query on status submission or when viewing an uncached view. Since statuses can change so often and views can be cached, I think it makes more sense to use a subquery on the (already efficient) {facebook_status} table.

Either way, I don't really understand the benefit of having another table with a one-to-one ratio to the current one, especially given that it would have the same columns.

I confirmed that the patch in #6 works and committed it to dev! Thanks Dave!

I'm setting this issue back to "active" since the existing patch has been committed (with a few minor string/comment changes). The next step is to integrate with User Views, however that ends up being achieved.

I looked into user-based views last night and I understand the problem better now. I still don't think the correct solution is to create a new table though--and I think that would require a new handler anyway to accommodate a double join. I don't quite understand enough about creating handlers yet to write the necessary user table joins to fit the current structure, but I'll try to look into it if no one else beats me to it.

:D

Great!

Thanks for the great module IceCreamYou!

OK. Here's a new patch that adds "Latest Status Update" to users. You can see from the code that it actually does it in the data hook instead of the data alter hook. It does it without setting up a relationship, so I'm not sure if this makes it unnecessary to have the relationship set up. Maybe it doesn't because that provides extra information. This will give the most recent status update right in the "User" option group though, which is probably the most likely use case.

Most of the patch didn't really work, but I took the handler and the idea from your changes to facebook_status.views.inc and modified it to get results that do work. The only problem is that it's kind of confusing to get the desired results, and also there's no way to sort by Status ID or time.

Anyway, I committed what's there. I want to try to make it possible to sort the results by Status ID and add a default view that implements latest-status goodness. (On that note, I don't think the current default view shows up at admin/build/views....) Then maybe I'll write some docs and we can finally put this issue to rest.

Yay, fixed! For those wondering, I took an easier approach and just figured out a way to filter to Last Status Update. That makes it *much* easier to understand what's going on, eliminating the need for docs on the subject, as well as getting rid of the need to do a custom Status ID sort handler.