Love Fuel?    Donate

FuelPHP Forums

Ask your question about FuelPHP in the appropriate forum, or help others by answering their questions.
Stacked event issue
  • adampattersonadampatterson
    Hello,

    I am building a CMS ( not using Fuel I know I know :)

    But I am using the events class from version 1.4 as the API for my plugins.

    After doing some testing everything seemed to work just fine.

    I could register, see if an event existed, unregister and also use the forge.

    I noticed a problem when I stacked events though, If I trigger an event named 'preview' that has two registered events and passing data to append to the string.

           $data = 'data';

            function callback_one($data = '')
            {
                return 'one '.$data.'<br />';
            }

            function callback_two($data = '')
            {
                return 'two '.$data.'<br />';
            }

            // Register the events to "my_event"
            event::register('preview', 'callback_one');
            event::register('preview', 'callback_two');

            $data =  event::trigger('preview', $data);
            $data =  event::trigger('preview', $data);


    The result looks like this:
    dataone data
    two data

    What I was expecting something like this:
    one data two

    I tried $content = event::instance('render_content')->trigger("preview", $data);

    But it returns an empty string.

    I would be grateful for any help.

    Cheers!
  • adampattersonadampatterson
    Looking further into this I think it could be the _format_return method.

                case 'string':
                    $str = '';
                    foreach ($calls as $call)
                    {
                        $str .= $call;
                    }
                    return $str;
                    break;
  • adampattersonadampatterson
    I might be wrong, But it looks like after one event has been processed that its data is not passed to the next event.


  • HarroHarro
    If I run your code, and dump $data:

    print(htmlentities($data).'<br />');
            $data =  event::trigger('preview', $data);
    print(htmlentities($data).'<br />');
            $data =  event::trigger('preview', $data);
    print(htmlentities($data).'<br />');
    I get

    data
    two data<br>one data<br>
    two two data<br>one data<br><br>one two data<br>one data<br><br>
    That looks ok to me?

    (this is 1.5/develop btw, but I don't think it had any changes side 1.4)

    edit: just checked, last change was over 6 months ago


  • adampattersonadampatterson
    So

    The way I see it,

    Something like this should be happening.

    callback_one receives the data giving you one data

    callback_two should receive one data, and output one data two.

    To me, it looks like callback_one is not returned to callback_two on the same event.

    If I use two different events then I get more or less what I would expect.

    I think both callbacks are triggered and then _format_return joins them.

    The issue with v2 of this Event API us that in order to pass data to a function you can no longer reference a function name.

    $container->on('my_event', function($event, $param1, $param2){
       // do stuff with $param1 and $param2
    });

    // Trigger the event with params.
    $container->trigger('my_event', 'param 1', 'param 2');

    # vs

    function my_name( $data ){
       // do stuff
    }
    $container->on('my_event', 'my_name');
    $container->trigger('my_event', 'Adam');

    This "works" But if I plan on using this in a plugin the event function can't be called in the plugin.
  • HarroHarro
    You are correct in that is isn't called in a chain, all events listening for a specific trigger will receive the same information, it hasn't been designed to pass data from one event to another.

    imho that would not be a good thing to do, if I register een event listener on a piece of data, I want that piece of data. I do not care (and possibly even know) that there are other listeners active, and I certainly wouldn't want the data passed to be manipulated along the way.

    Your usage of the Event class is different, we'll have to see if we can accomodate the two scenario's in v2.0.
  • adampattersonadampatterson
    With 2.0 I seem to get the same results as 1.4 



  • HarroHarro
    As said, it's currently not designed to pass data from one event to another. Each one will receive exactly the same data, and in general that is a good thing, event handlers should not be dependent on each other.

    @FrenkyNet is responible for the 2.0 library, if you are looking for different behaviour contact him to see what's possible.
  • MaxZnMaxZn
    It is possible to use AOP instead of the Event? That would solve a lot of problems, in particular the problem of duplication through code. What do you think about this? Found the library, which you can pick up to the application without changing the core. Here's a look https://github.com/lisachenko/go-aop-php
  • adampattersonadampatterson
    Thanks I will take a look.

    It could be that I am thinking of events in the wrong way.

    It would seem like they are ment to do tasks that dont return data.

    Otherwise I don't really understand the advantage of using events at all, would filtering be the correct term?

    Register events and then "filter" them rather than trigger them.

    I would be better off going:

    $content = do_this($data);
    $content = do_that($data);



Add a Comment

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In Apply for Membership

Categories

In this Discussion