Friendlist integration

I am shamelessly subscribing to this :)

Yes, I've been intending to refactor the facebook_status_get_ur_status function for awhile to be more generic. Unfortunately, the way it's written right now has a lot of code specific to UR... but really, it should be rewritten so that it just passes an array of UIDs to facebook_status_get_status. Then we also need a way to choose the relationship type... haven't really thought that one through yet, and it's complicated because one-way and two-way relationships require much different treatment.

But I doubt anyone would have more than one UR*/FL*/etc. module installed at once, so I don't think we need to create a new form for that.

Also, I probably won't get to this for awhile. If you have any inclination to work on it, code will be most welcome.

Hi.

I worked on this tonight some, and I'm nearly there, but won't be able to finish until next weekend.

Could you write me three functions?

The first function should return an array of relationship types. It should take the parameter $advf = FALSE and include something like this:

  if ($advf) {
    $fbsur[-1] = t('Any relationship');
    $fbsur[-2] = t('Ignore relationships');
  }

The second function should build an array of the UIDs matching the current user's friends, pass it to facebook_status_get_status(), and return the result of passing that to facebook_status_list_render(). (Don't bother testing with facebook_status_get_status - it won't work.) This function should take the parameters $rtid, $num_results, and $group. Your code will probably conclude something like this:

    if ($group) {
      $number = -abs($number);
    }
    else {
      $number = abs($number);
    }
    $statuses = facebook_status_get_status($uid_list, $number);
    return facebook_status_list_render($statuses);

The last function is for advanced_forum integration. It should take the parameter $account which is the full user object for the author of the relevant comment. It should then return a true or false value based on whether or not the current user has the correct relationship type with $account. The chosen relationship type is stored in variable_get('facebook_status_advf', -2), and remember that a value of -1 indicates "any relationship" and a value of -2 indicates "ignore relationships" (just return TRUE). Also keep in mind the difference between mutual and one-way relationships.

Thanks. If you need help on any of this I'll try to assist as much as I can.

I still have to figure out how facebook_status is going to decide which friend module to look for at all the various places it needs to know... but that's not terribly difficult. Oh, and I've been developing on 5.x instead of 6.x so I can actually test, so I need to port my changes too. :-P

subscribing

1) Yes, that's what I mean.

2) Yes, that's fine; yes, that's what I mean.

3) The relationship type doesn't need to be passed as a parameter because it's stored in a variable. But if it's easier for you to write it that way, that's fine; I can fix it afterwards.

Good enough for me. I'll see what I can do.

I have it working one-way for UR types - one-way meaning if the relevant user is a "fan" of another user then the "fan" can see the relevant user's status, but not the other way around.

I think. I might have to check that actually. I'm going to change it to what I wrote above if it's not already that way though.

I will definitely be subscribing too. Would be exceptional to get these modules working together.

I doubt it will make a huge difference for my development because I need pretty specific things from the database... so I'll keep doing what I'm doing, and just let me know when the API comes out so I can take a look and implement it if possible.

Fair enough. I'll implement the API when it gets released. Until then I'm not going to hold anyone else up... if I find the time to get a release out before you do. ;)

Just a heads-up: I've restructured the API in the 5.x branch. It will be at least Wednesday before I port the changes to 6.x - more likely Friday or Saturday. At that point I'll finally add in the Friendlist integration, which may not happen until as late as Sunday.

That's fine. I'm pretty sure I'll be ready for integration next weekend, but there's no rush really to actually integrate until there's a simple and effective way to do so.

Okay. I'll see what I can do... it may or may not be this weekend, I'm getting a lot more work than I expected.

I've just ported changes from the 5.x branch so the next thing on my list (which I'll get to either tomorrow or next weekend) is integration with this new API. If the "coming soon" documentation was better by then it would probably help... ;)

Okay, but I'm confused about why you'd use the $relation_name instead of $rtid. And I'll have to look at module_invoke_all() some more.

I don't understand. I don't think there are any APIs that don't use an RTID, and if you're just doing a database call why should it matter what relationship type the RTID stands for? Anyway it's *way* easier to get the RTID from user input; otherwise every developer has to do an extra database call using the RTID to find out what the name of the relationship type is.

I used to use Buddylist, I now use User Relationships, and I've looked at FriendList some. To the best of my knowledge, they all use RTIDs the same way.

I still don't understand why that's a problem. You're not going to be looking at more than one table at once. There is no use case where more than one relationship module is going to be installed at once. If there is, it doesn't make any sense to get relationships from all modules at once: even assuming that there's a relationship in both modules with the same name, there's no guarantee that they are intended for the same thing (and in fact if you have two modules installed they probably aren't intended to do the same thing).

The RTID is far easier to work with in terms of form elements and such, and there's no reason to worry about capitalization. Also it lets you do custom DB calls if you need to reference other tables; because you'll never find a string used with Joins.

Can you explain a case where it would be a bad thing to have the RTID in the API? Maybe that would clear it up for me.

Modules which adhere with the API make sure that theree aren't two relation types with the same name.
The problem would be there if you decided to use the "flag" module for 1-way relations, and friendlist for 2- way relations. (Yes, flag will be one of the modules supporting this API).

What if you had a flag called "Friend" to mark that, say, an image was of one of your friends; and a FriendList relationship type also called "Friend"? Are you telling me Flag and FriendList won't let that happen?

you want to use user relationships for 1-way relations (because it allows you to define them so that you need confirmation) and friendlist for 2-way ones. What if both of them have the same for the two different modules?

Same thing--how are UR and FL supposed to know if there's already a relationship type with the same name? Basically, my point is that you end up with the same issues whether you're using RTIDs or strings, they're just slightly different cases.

As far as using RTIDs with form elements, they make it easier to manipulate the order of elements in '#options' arrays. Not a big deal, really.

For DB calls, the reason it's an issue is because if you have a relationship type (say "friend") and you want to find out whether two users are friends (I know there's an API call for this, but it's an example) in the {relationships} table then you'd have to JOIN on the {relationship_types} table; but if you had the RTID you could skip the join and just query the {relationships} table. It's an efficiency concern, albeit a relatively minor one. It's why indexes are almost always numeric; the same reason why any kind of ID exists.

There's another rare but potentially critical issue with using strings: the string '0' is evaluated to FALSE, so you could end up with cases where modules need to check if a relationship type exists and the wrong result is returned.

I'll take your word for it, except for the 'string zero' issue. The reason this could be a problem is if you're evaluating things in a loop, so you don't know what's going to come up. Obviously there's no reason to check if a relationship exists if you've just grabbed it using the API. Still, not really worth worrying about I suppose; and really if it's ever a problem it's a problem in the modules themselves.

Anyway, it's going to take longer than expected to get this into facebook_status. I find myself having less and less time these days, and I have to test that the changes ported from 5.x don't break anything in 6.x.

Eh... I'm going blank. I had a good example but I forgot what it is. I'll post back if I remember it.

Okay, here's one example I'm encountering ATM.

How am I supposed to assign a default relationship to a variable that I'll need to use with the API? If I can't assign a default relationship, none of the relationship stuff will work until a relationship is expressly assigned. That's a major problem for me right now, because my settings form isn't working. :-p

A *good* alternative for me would be if there was a way that I could pass the RTID to the API and get the relationship name returned. This would also save a *lot* of effort on my part rewriting a good part of the module.

A string has to be arbitrary. For example I could assign the string 'Friend' but a lot of people aren't going to have a relationship type called 'Friend.' If I assign a blank or arbitrary string, I get no results until the variable is explicitly set. But if I'm using RTIDs instead, I can assign zero as the default because there's pretty much always going to be a relationship type of zero if there are relationship types at all.

As I'm thinking about this more, I suppose I could invoke the function that grabs relationship types and just use the first one that comes up, but that takes *way* more work each time I want to use variable_get().

*sigh*

Am I supposed to use 'name' or 'plural_name'? Both are stored in the database at least for UR. Which one gets returned and which one do I pass?

It becomes relevant when the name is displayed. I think there's another reason too that prompted me to ask but I'm not at my work PC right now so I can't check.

I just checked - the reason I needed to know was that I have a block called "[plural-relationship-name]' recent status updates," i.e. "Friends' recent status updates."

So... maybe there should be a new function to grab the plural form, if it exists?

function friendlist_socnet_relationship_plural($relationship_singular) {
  //Return as an array in case there is a relationship with the same name in two different modules.  It shouldn't happen, but we'd rather be safe.
  return array('friendlist' => db_result(db_query("SELECT plural_name FROM {relationship_types} WHERE name = '%s'", $relationship_singular)));
}

I can't think of another name. For the sake of argument, let's say our relationship type is called 'Friends.' My original title would then be "Friends' Recent Status Updates." The only substitute I can think of that wouldn't require the plural would be to use a neutral word like "Relationship" which doesn't work out too well.

Yes, but module_invoke_all does an array_merge on the result, so you'll just get one array returned. It's a bad idea to have two relationship types with the same name, so modules invoking the hook can just use the first item in the array. The only reason I used an array in the hook I wrote above was to facilitate array_merging. (But you're right, the key would have to be numeric.)

That name is way too long and clunky, and would definitely cause a "WTF?" for me if I saw that on a site.

I'm postponing this because it's taking up more time than I have right now and I'm having trouble getting it all sorted out. Sorry.

Yes, although the goal of any module should be to 'just work' without configuration... ;)

...theoretically if the module is well-written any text should be possible to change...

subscribe

subscribe

subscribe

subscribe

subscribing - would love to see this happen, especially for with the Flag module.

I don't know how quickly I'm capable of doing it, but I have some free time now finally, so I'm definitely planning to get to this soon.

*Sigh*

As much as I would love to do this, it's more complicated than I'm willing to tackle at the moment. I may or may not decide to work on this in the next two weeks or so; after that, there's not much chance I will have time to add this feature without help. Of course, if anyone can write a patch, that would be awesome, and I'll be greatly impressed that you understand the code well enough to do so because this stuff is by far the most complex logic in the module and my approach didn't make it any easier. :P Writing a patch would basically involve searching for every instance of 'ur' and 'rel' in the code and looking to see how the User Relationships implementation was done.

Hey,

late to the discussion, have not gone through all the messages. Just wanted to mention that integration with this module is very high on the priorities of FriendList module and we will renew efforts very soon.

Thank you.

Sounds good. If someone can hack out a patch that works and looks good I'll commit it. I am planning to completely rebuild the module at some point though... I don't know how long it will be before I get around to that, but this will definitely be a priority when the time comes if it hasn't already been implemented.

It would be great now when FacebookStatus is in version 1.0. when it will be have friendlist integration or to have some news about it.
I really like to use it but I am really missing friendlist integration.

Thanks
Igorik
http://www.somvprahe.sk

First of all, if someone writes a patch for FriendList integration in FBS 1.x, I will probably commit it.

However, I'm going to be spending most of my effort rewriting a good part of the module for the 2.x branch. FriendList integration will be in the 2.x branch, but that will likely be at least a few months away; and no one can work on FL integration in FBS 2.x until the API is finalized.

I apologize for the delay, but it is unfortunately necessary to make the module as versatile as possible.

That said, it's not very hard to manually integrate FBS with FL. The API functions for both modules should be simple enough for almost any use case. If anyone needs help doing this, feel free to open a support issue and I will help as much as I can.

The 2.x branch is now practically complete, and is in CVS/dev. A few things remain before I will create an official release, and Views integration is one of those things. I believe that Views integration should take care of this issue as well (as discussed here) so I'm marking as duplicate.

I do need some help with Views integration though. We'll see how that works out.