How to say hello to another gadget (Events part 2)

Author: Pablo Fischer
Date: June 2nd 2005

The idea

First of all I suggest you to read the first draft about Events.

Ok, Now I can be sure that you have read that draft so I can share you my great ideas and why I think Events are so important, but for a very good explanation lets imagine we have the following problem:

You have a job in a company and they ask you to hack two gadgets: Customers (to deal with them) and Sales (to have money ;-)). As you know the only people that can increase your sales are the customers, so they have a link.. imagine they are married :-P.

Hacking those gadgets is the easy part: you write their JawsGadgetInfo, Gadget, Model, write their i18n files and bravo!, You have them… but wait!. Can you go back 5 seconds? Open your DB design and you will find a field in the sales table called customers_id, this is obvious, you need to do a ‘relation’ between them: how many sales have been made by a customer,for example.

Now, suppose you have a boss that has the great idea to tell you: Hey, why not having an option for customers to delete their record?. There are many reasons to do this, for example that your customer comes back in the next three days and he tells you: “Hey, sorry, but I don’t want to be in your Database” or any stupid reason, then, what? you need to delete the user from the database.

After some phone calls your boss gives you permission to delete the customer from the Database.. but wait! You also have some data of your customer in other gadgets (the Sales gadget!). But you don’t know that the Sales gadget exists (you _know_ but the gadget doesn’t, computers are so stupid sometimes). So, how to tell a gadget or all the bunch of gadgets you have that you have deleted a customer?.

So, you are now in a big problem:

How to say hello or goodbye to other gadgets

There are two solutions:

  1. You can edit the Customers model and add some code after you delete the customer to do some other stuff with another gadget (Sales imagine), but then you want to do other stuff with another gadget… and that happens, trust me :-). You don’t want to be hacking the model everytime you have a dependency with another gadget, right?.
  2. Use Events (triggers, no tigers). This is the best solution because everytime the model executes an action or method (the name doesn’t matters) you will be throwing an ‘event’ or ‘flag’ to the Jaws system telling: “I’ve deleted a customer!”, for example. Then, the Jaws System should take a look to the gadgets that are waiting for that call (like waiting the phone from your girlfriend but you are in the bathroom and you mother answers the phone, you need someone to passes you the call/phone!).

We know that the first option should not be used, the second one should be used, but we are in another problem:

Different ways to say hello and pass the ball

There are many ways to say hello and to know who to say hello and most important: to know which message/data we will send.

  • Use a database table as a ‘pool’ of listeners. In this table we will have the gadgets that are waiting for a call, the call they are waiting and which method is going to receive the call.
  • Use the registry and JawsGadgetInfo. This options is not recommended, because everytime we (Jaws System) catch a trigger we should look in the registry for the installed gadgets and execute the JawsGadgetInfo of each one to know if some gadget is waiting for the call (we should knock the door of each gadget).

The first option is better because is better to have a ‘directory’ with all the gadgets and calls they are waiting than to include each file located in the registry, create the object and read a whole array just to see if some of these gadgets are waiting.. then if they are waiting for the call we should invoke the model.

Say Hello in code, an example

A brief example of implementing this can be:

First, to declare in the gadget Model which calls our gadget will have, taking the first example: Customers, we can have:

$shouter = new EventShouter();

With the code above inside the InstallGadget method we are plenty sure that this ‘shouters’ (to give them a name) will be installed in a database called: gadget_shouters which will have 2 fields: gadget and call, for example:

Gadget Call
Customers onDeleteCustomer
Customers onUpdateCustomer

But how to add ‘listeners’ (gadgets that will be waiting for these calls). An example can be:

$listener = new EventListener();

The code above should be in the Sales gadget and in the InstallGadget method, so when the user decides to install the gadget these calls will be saved in a database table called: gadget_listeners which will have the following data and structure:

Gadget Call CallResponse
Sales onDeleteCustomer DeleteSale
Sales onUpdateCustomer UpdateSale

So, when Jaws hears the ‘onDeleteCustomer’ call it will take a look in the gadget_shouters to see if the call is valid and if it its then it will take a look in the gadget_listeners to find which gadgets are waiting for the call, it will find a gadget called Sales that is waiting the ‘onDeleteCustomer’ and wants the ‘DeleteSale’ method to deal with the call.

I missed something?

Yes, now the gadgets can interact with each other, but how does a gadget knows which data the other gadgets are waiting for? For this we need to make a Guideline for coders (and developers :-P). Some nice stuff to send can be:

  • Params that the method throwing the trigger has. For example the onDeleteCustomer is going to be called from the CustomerModel::DeleteCustomer method, this method requires a param called $id, so a nice idea is to send it.
  • Return (expected): We can also send the expected result, if we are sure we are returning a true or false from CustomerModel::DeleteCustomer, we should also attach it to the trigger.
  /var/www/wiki/htdocs/data/jaws/proposals/eventstrikes.txt · Last modified: 2007/11/02 16:27