Clarification on parameters and arguments [with pizza offer]

Hi,

Sorry, I don't mean to be a pain and reopen issues, but I am simply absolutely utterly lost.

> >Do I have to do something to make it "identifiable"?

> yes, read the comments of the methods of the rules_data_type class.

OK.
I have no way to test this because I am not sure when this method is used. Since the identified is the string itself, would this work?

/**
* Rules relation_status data type
*/
class rules_data_type_relation_status extends rules_data_type {

 function get_identifier() {
    $id = &$this->get();
    return $id;
  }

}

...? OR, judging by looking at the code, do you think that I should make those fields unidentifiable?
(I tried, and things still seem to work)

>>So... Here is the question. Is *this* the difference between a configuration option and an "argument"? That is, an argument will always show >a form with the list of possible ones, taken from the generating event?

>>If the answer is "yes", that is, if I got it right, should the documentation be fixed?

>No, the select is shown when the data type is not identifiable.

Question: I marked the data as identifiable ('identifiable' => FALSE,) but I am not sure why. I assume that the Rules module decided that they weren't identifiable since the method was missing. Right?

Question 2: What I am seeing in the arguments is a select box which a list of possible arguments passed to the action. Is that not the intended behaviour? It's immensely handy...

> However it makes sense to fallback if
>get_default_input_form() is not implemented by the data type. I'll implement that.

Sorry, I simply have no idea what you are talking about.

What I *do* know, is that when I use arguments I am getting an input form which makes me select one *event parameter* amongst the ones of the matching type, as I explained above. Right?

> >If I didn't get it right _at all_, can you tell me what I got wrong?
> Usually arguments change on execution time, settings not.

OK. I am now *starting* to get what you mean.

I don't suppose you could please (and I mean it in a begging sort of way) have a look at this:

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

And maybe even install friendlist:

http://drupal.org/project/friendlist

And let me know if I did anything immensely stupid? It took me countless hours to get Rules integration right, and...

If you do, I will order 2 pizzas for you tomorrow night (I am dead serious about it).

Bye,

Merc.

Hi,

About buddylist2: did you actually see the code?
I did, and there isn't much there. I found it hard to communicate by email with the Buddylist2 developer.
Friendlist the other hand is _complete_, and it works (well, it works in my devel installation and for Marius -- I will check why you got the file not founds...). I can only advice the buddylist2 developer to have a look at Friendlist if he wishes to continue develop Buddylist2 (for which CVS commits are sporadic). Since I need to _enjoy_ programming, rather than battling various barriers, I developed FriendList in 2 weeks. It's a matter of time optimisation. Not many people can produce 7000 lines of working code in 18 days, and I need to work at my speed rather than anybody else's.

Now, having settled that:

>>I have no way to test this because I am not sure when this method is used. Since the identified is the
> > string itself, would this work?
> yes that would work fine.

OK cool.

>>What I *do* know, is that when I use arguments I am getting an input form which makes me select one
>> *event parameter* amongst the ones of the matching type, as I explained above. Right?

>In case of the data type is identifiable. If it's not, its default input form will be added instead (e.g. a textfield for
> strings) which is used to create a new instance of the data type on the fly.

That's the thing. I *like* the feature where users are given a list of possible options amongst the parameters. I think it's fantastic. I have the feeling that I will lose that feature...

>>class rules_data_type_relation_status extends rules_data_type {
> you can just remove that and user rules_data_type instead.

If I do that, what would I put in this form?

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

        'relation_status' => array(           <--- HERE
          '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',
    ),

...?

>> 'description' => 'The relation type'
> I'd say descriptions like that doesn't tell anything more than the label and can be removed.

I agree. However, it does the _nice_ think of giving a select list amongst the "action" argument, which is _fantastic_.
Will I lose that if I manage to use the default data type? And what about the nice custom tokens I have going? Hummmm...

> don't place token integration in the rules integration include.

Wooops... OK.

> Why a separate module for rules integration? I personally dislike unnecessary modules cluttering
> the modules page.

I made everything modular... some people might not want to use it

> As you already know, identifiable data types need to implement some methods..

Which is done! You said the code was OK... is the *one* method enough for my data type? (if I keep it)

> Apart from that the code looks ok.

Huge relief...

>Regarding message handling: buddylist2 can use workflow-ng for messages - it does so by default rules once >workflow-ng is active. so one can customize the messags by changing the default rules, which I think is a great
> feature.

Friendlist has _fully_ configurable, translatable message going from ANY status to ANY other status... I think it's better that way.

>I've also shortly tested your module. I wasn't able to establish a friendship connection, I always got: 403 page not
>found errors on paths like /friendlist/add/11/1?destination=user/11. Furthermore I saw no admin interface for
> managing relation types or other settings!?

Oh dear. I tried and tried but could not reproduce this. The module is working fine for 5 beta tester I am dealing with...
Can you tell me what you did to reproduce it?
I would _love_ you to actually have a look at what you see with the FriendList rules integration to see the forms you get... or maybe there is no need.

Also, are you not getting /admin/settings/friendlist_ui ?!?

Which version did you download precisely?

> So where's my pizza? ;)

I am _dead_ serious: PLEASE send me your address through the contact form, and tell me a day when you are _definitely_ going to be home and hungry with a friend...)!

The Pizzas is not for this issue -- it's a token to say "thank you" for developing Rules.

Bye!

Merc.

Hi,

(Plus, I sent you an email about Buddylist2 -- please respond.)

Merc.

Hi,

Ping?

Merc.

Hi,

Thank you for your help. I really appreciate it.
Like: _REALLY_.

> I've used the latest dev snapshot.

That's just so strange...

> I've tried again now, now it's working better. Don't know what changed in the meantime though? Perhaps it's
> somehow
> related to a cache.

Well, *nothing* has changed... so I guess it was a cache issue.

>>Now the UI is also there. But I must say, the message configuration page is quite confusing.

It is indeed. It needs improving. But, it's there -- this is a UI issue.

>>Friendlist has _fully_ configurable, translatable message going from ANY status to ANY other status... I think it's
>>better that way.
>As long it's t() one can this manually nevertheless. The advantage with bringing it to rules like I mentioned is, that
>you can make use of any tokens and php code then too.

Messages cannot be decided by Rules, simply because you don't know who is going to display them.
For example, this:

 'OW_NONE' => array(
        'description' => 'No relationship',
        'on_add' => array(
          'link' => 'Become a !rt_name of this user',
          'screen' => 'You will become a !rt_name of this user',
          'message' => 'You are now a !rt_name of this user',
        ),
      ),

Tells you that if you don't have a one-way relation with a user, you will be shown "No relationship". There is an available option there: "Add". If you add a relation, "link" will have the link string, "screen" the will have the pre-confirmation message, "message" will have the post-confirmation message (yeah, the current names suck). Now, this could be done with _any_ UI. I have a developer who is implementing an Ajax front end for it. The Ajax backend will need to return the 4 strings to the ajax frontend, so that the frontend knows what to do and what to show.

Using Rules for messages will make this impossible. The messages are part of the architecture -- and it's part of the power of FriendList's API, which was designed by my poor autistic mind going through a binary graph of some hundreds use cases as I stared walked in a circle (...).

> After making a friendship request I get redirected to the wrong path
>https://mysite/drupal-6/drupal-6/user/9 - I've drupal in the path drupal-6.. (instead of https://mysite/drupal-6/user/9)

Wooops... fixed. Thank you again. None of the testers had Drupal in a subrid!

> @data type: If you want to keep the select, best just make the data type identifiable and implement get_identifier
> as above.

Ok, can I ask you as a last favour to please confirm that this looks OK:

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

Also, I really think the documentation needs to be fixed. I still haven't _quite_ understood how arguments are dealt with, in terms of select boxes, or raw input, etc. If I got it 100%, I would be able to improve the current documentation. But... I am obviously not smart enough for that.

What I really think needs to be clear, is the "argument" part of the deal. The "settings" part of the deal is clear. But for "arguments", what I am *seeing* doesn't seem to match what the DOCs say -- or what you are saying right now!

Once again, what I am seeing is that if you use arguments, you are basically talking about what's been passed to the action if the argument is definable. Is that correct? And what if the argument is _not_ definable? What if you wanted a string as a an _argument_ rather than a config option? If you answer here, I will work on the docs. Or, maybe fix the docs directly...

Thanks a lot,

Merc.

Hi,

"If you specify an argument with an identifiable data type, rules will work with an argument mapping, which maps existing rules variables to the argument defined. Else it will use the default input form on configuration time and then create an instance of the data type on the fly and passes it to the action.

If the argument is undefined which may happen (e.g. a node, which is to be loaded doesn't exist any more), rules will abort and don't execute any actions that need it."

***PLEASE*** add _exactly_ this to the handbook!
I would have saved hours and hours of work knowing this!

Merc.

Hi,

"@rules_data_type: hm, get_identifier is not enough. I think there is also an method called load or so you'll need to implement. Check the docs or the comments in the rules_data_type class - they tell you which methods you need."

There is no way for me to test this... Can I maybe ask you to do please (and this ia favour, I realise that) send me a template load function which would work with:

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

...?
I am sure I would screw this up badly... and I realise this is way more than you're meant to do as a maintainer -- sorry.

Merc.

Hi,

Alright, it wasn't that hard. I think i did it myself:

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

The load method is there.
Fago, do you think the data definition looks complete now?

Merc.