Hi,

I have just spent a _lot_ of hours while integrating FriendList with Rules. Now, I have two issues:

1) I am not sure I did things right
2) I feel the compelling _need_ write documentation about it. I am not a particularly good programmer, but I can write documentation. I can only do that once I've understood exactly what is going on.

Rather than just asking "is this OK?", I'd like to fully understand what's going on so that I can actually write a fantastic tutorial about it. As you will see from my questions, my understanding of this is still quite foggy.

So, you will see the code at the end of my post. Now, questions:

* What is an "identifiable" data type exactly? If you look at my code below, you will see that I defined the data type "relation_status" as identifiable. This means that there is no need for a form for it... right?

* What is the difference between configuration options and parameters , really?
The official documentation doesn't seem to match reality about it. I am immensely confused! Please allow me to tell you what I understood after a lot of trial&error, reading Rules' source code, and a bit of intuition.
From my understanding, "arguments" only really make sense when, while executing a comparison, the admin needs to pick one of the arguments passed from the event. That's what I did friendlist_rules_rules_condition_info():

 'rules_condition_relation_status_compare' => array(
      'label' => t('Compare with a status.'),
      'arguments' => array(

        'relation_status' => array(
          'label' => t('Relation status'),
          'type' => 'relation_status',
          'description' => 'The relation to compare'
        ),

      ),
      'help' => 'TRUE is returned if the relation status equals the string in the input box',
      'module' => 'Friendlist Rules',
    ),

I basically want the admin to pick amongst one of the two statuses available from the event. Note that there's a form attached as well:

/**
 * Action drupal message configuration form.
 */
function rules_condition_relation_status_compare_form($settings, &$form) {
  $settings += array('status_param' => '', );

  $options=array();
    $status_data=friendlist_api_status_data();
    foreach($status_data as $key => $v){
      $options[$key]="$key -- ".t($v['description']);
    }


  $form['settings']['status_param'] = array(
    '#type' => 'select',
    '#options' => $options,
    '#title' => t('Status'),
    '#default_value' => $settings['status_param'],
    '#description' => t('The status to compare it with'),
  );
}

This will make sure that... there's something to compare the status with. And that's taken from a list of possible states. Now, since the status is identifiable, it doesn't need a form for itself. But...

* What's the use of having un-identifiable fields as arguments, if they should effectively be settings? This questions is important... also because sometimes if I tried to add some un-identifiable fields to an action, Rules simply made it unavailable!
If you change friendlist_rules_rules_action_info() so that it has, in rules_action_friendlist_add():

    'rules_action_friendlist_add' => array(
      'label' => t('Create a relationship between users'),
      'eval input' => array(
        'user1_param',
        'user2_param',
        'rtid_param',
        'message_param'
      ),

      // ADDED TO TEST IF THE RULE IS STILL THERE
      'arguments' => array(
        'something' => array(
          'label' => t('Requester user ID'),
          'type' => 'integer',
          'description' => 'The requester of the friendlist action'
        ),
      ),

      'help' => 'Create a relationship between users',
      'module' => 'Friendlist Rules',
    ),

The action is no longer available. My only reason for that is that the event doesn't have any "integer" values, and therefore will not consider that action as a possible one for the event. Is that right?

So... having an answer to these questions would be _grand_. Please have a look at the code below, to see if I did anything silly or if I did things "Rules-way".

Thank you!

Merc.

P.S.
I was going to attach the code... however, it makes more sense to put a link to my CVS:

http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/friendlist/...

Comments

amitaibu’s picture

I'll try to answer, although I'm no where as knowledgeable as fago:

1. identifiable - means you are able to retrieve the data by an id. For example a node is identifiable because you can node_load() the nid.

2. Indeed argument is a data you pass to Rules, and it can preform actions on. I'm not sure you need to define an argument with new data type. Your argument can be a string data type that will hold the relation status. Later admin can use condition 'compare text' to check it.

3. form looks ok, I think you can remove the $settings += array('status_param' => '', ); part.

4. I didn't really get the last question about the argument. An event will be triggered only if you have all the required arguments present. If you need to load new arguments you have the 'new variables'. In this example a new node argument will be added through the rules_action_add_node() settings:

      'new variables' => array(
        'node_added' => array(
          'type' => 'node',
          'label' => t('New content'),
          'save' => TRUE,
          'label callback' => 'rules_action_add_node_variable_label',
        ), 

mercmobily’s picture

Hi,

Thank you for your answer!
OK, let's see.

-----------------------------------------------
1. identifiable - means you are able to retrieve the data by an id. For example a node is identifiable because you can node_load() the nid.
-----------------------------------------------

I am more interested in knowing what the _practical_ implications are. Right now, if I don't define my new data type as "identifiable", Rules won't give me a select box to pick which event argument to use amongst the ones that were passed (in particular, status_pre and status_post). I am not sure why though -- and I am not sure that what I am doing is right.
The "status" Data type is indeed identifiable -- and so is the relation type id. The status' ID is... the status itself. Same for the relation type id, actually...
Now I wonder: I haven't implemented the function get_identifier() for neither of them, and yet things are working. Hummmmm...

-------------------------------------------------------------------------------------
2. Indeed argument is a data you pass to Rules, and it can preform actions on.
--------------------------------------------------------------------------------------

So are the "settings", really. I was trying to figure out the difference between the two...

--------------------------------------------------------------------------------------------------
I'm not sure you need to define an argument with new data type. Your argument can be a string data type that will hold the relation status. Later admin can use condition 'compare text' to check it.
----------------------------------------------------------------------------------------------------

Yes, but right now it's *nice*: The user has a select box with the list of possible statuses (status_pre and status_post) and then needs to pick, from the settings, which status to compare that too. A user will get it in no time.
Doing it as a string wouldn't be as nice: the user would need to put the tag [status_pre:raw] or something like that.

--------------------------------------------------------------------------------------------------------------
3. form looks ok, I think you can remove the $settings += array('status_param' => '', ); part.
---------------------------------------------------------------------------------------------------------------

OK.

------------------------------------------------------------------------------------
4. I didn't really get the last question about the argument. An event will be triggered only if you have all the required arguments present. If you need to load new arguments you have the 'new variables'. In this example a new node argument will be added through the rules_action_add_node() settings:
-------------------------------------------------------------------------------------

I get that. So, if you define new arguments that are not part of the original event... like a new text string, etc., the action won't be listed as an available one! (This is what I am getting by testing the code).

I am still not clear on this:

* What is the difference between configuration options and parameters , really?
The official documentation doesn't seem to match reality about it. I am immensely confused! Please allow me to tell you what I understood after a lot of trial&error, reading Rules' source code, and a bit of intuition.
From my understanding, "arguments" only really make sense when, while executing a comparison, the admin needs to pick one of the arguments passed from the event."

I think I am missing something here... a crucial piece of the puzzle.

Bye,

Merc.

fago’s picture

The action is no longer available. My only reason for that is that the event doesn't have any "integer" values, and therefore will not consider that action as a possible one for the event. Is that right?

yes.

3. form looks ok, I think you can remove the $settings += array('status_param' => '', ); part.

no, leave it. This ensures that $settings['status_param'] is set.

* What is the difference between configuration options and parameters , really?

Configuration options are intended to be set when the action is configured and are fixed then. They configure the action once before it is executed with different data later.
In contrast to that arguments are supplied on execution time, you just configure which variable should be passed to the argument later.

Yes, this is getting a little bit blurred with configuration strings, that are evaluated on execution time (token, php input). So they are somehow both, configuration and an argument. So what a special string should be (configuration option vs argument) depends on the use case and how the semantics fit best - possible is both.

-----------------------------------------------
1. identifiable - means you are able to retrieve the data by an id. For example a node is identifiable because you can node_load() the nid.
-----------------------------------------------

Yes that's it. As there is no way to load or even save not identifiable variables, it's useful to have a small form that creates the variable directly - as it is e.g. for strings. So right now rules assumes that you create an input form for not identifiable arguments. We could improve that to fall back to the variable mapping select if there is no such form. (I think it doesn't do that yet).

>Now I wonder: I haven't implemented the function get_identifier() for neither of them, and yet things are working. Hummmmm...
This is only used when variables are packed when rule sets are scheduled.

fago’s picture

Status: Active » Fixed

If you have further questions, please reopen.

Anonymous’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.

mitchell’s picture

Component: Code » Documentation

Updated component.