Forums

5.7 Event Handling Changed

Permalink
Just thought I'd post this as another new found thing in 5.7 for people to watch out for who have these delightful packages, the Events for Concrete5 seem to have changed. Honestly I didn't use them before, but whilist creating my dummy accessibility package I came across the need to set an on_before_render event and found myself struggling a bit with how to get it working.

After some code searches I was able to come up with the following:

public function on_start() {
        $u = new User();
        $g = Group::getByName("Administrators");
        if($u->inGroup($g) || $u->isSuperUser()) {
            Events::addListener('on_before_render', function(){
                    $view = View::getInstance();
                    $html = new Html();
                    $view->addHeaderItem(
                        $html->css(
                            "accessibility.css",
                            'accessibility'
                        )
                    );
                }
            );
Viewing 15 lines of 17 lines. View entire code block.


Hopefully this will help anyone looking to start converting some of their packages that use Events and give a heads up as one more "breaking change" that I hadn't really seen posted anywhere else.


P.S. Anyone have any idea why the SuperUser wouldn't be put into the Administrators group by default? Has this always been the case?

Full "package" sitting athttps://github.com/ExchangeCore/Concrete5.7-text-icons... if you need to see more
exchangecore
 
JohntheFish replied on at Permalink Reply
JohntheFish
Neat solution for the control bar (but it wouldn't get through the PRB - missing t() functions ;-) ).

The super user has never been in any groups, not even administrators.

Apart from the use of an anonymous function, the on_start code you have setting up an on_before_render handler is very similar to existing pre 5.7 event handlers. Am I correct in assuming this would also work if you declared an on_before_render function and inserted Controller::on_before_render in place of the anonymous function?
exchangecore replied on at Permalink Reply 1 Attachment
exchangecore
Huh, well maybe I'll have to switch to some javascript to get my translations working ;)

Also, I tried the following code and received an error, I would have thought I could have passed a non-anonymous function into it, but when I tried it threw a fit (see attached). Weird. I also tried with self::on_before_render() but wound up with the same error. 

public function on_start()
    {
        $u = new User();
        $g = Group::getByName("Administrators");
        if ($u->inGroup($g) || $u->isSuperUser()) {
            Events::addListener(
                'on_before_render', $this->on_before_render()
            );
        }
    }
    public function on_before_render() {
        $view = View::getInstance();
        $html = new Html();
        $view->addHeaderItem(
            $html->css(
Viewing 15 lines of 20 lines. View entire code block.


But, as soon as I wrapped the function call in an anonymous function it worked like a champ.

public function on_start()
    {
        $u = new User();
        $g = Group::getByName("Administrators");
        if ($u->inGroup($g) || $u->isSuperUser()) {
            Events::addListener(
                'on_before_render', function() { $this->on_before_render();}
            );
        }
    }
Shotster replied on at Permalink Reply
Shotster
> Also, I tried the following code and received an error

Events::addListener(
   'on_before_render', $this->on_before_render()
);

I believe that's because you're invoking the function - not referencing it. You should be able to pass a "callable" as the second parameter...

Events::addListener(
   'on_before_render', array($this,'on_before_render')
);

That said, it's unclear why you'd want to put an on_before_render() method in your package controller. Your original closure approach seems more elegant (better) to me.

Also, I would encourage the adoption of the new IoC approach to loading classes which the Laravel framework affords. Thus, instead of...

$html = new Html();

...you'd have...

$html = Core::make('helper/html');

The advantage is that your code won't break if the underlying helper class name changes down the road. NOTE that this requires a "use Core;" at the top of your file.


-Steve
Shotster replied on at Permalink Reply
Shotster
> Also, I would encourage the adoption of the new
> IoC approach to loading classes which the Laravel
> framework affords.

BTW, this applies not just to helper classes, but rather to all "Loader" calls. They can generally be replaced with a call to Core::make(), or they can be accessed through a facade if one is available - for example...

$db = Database::get();

...instead of...

$db = Loader::db();

You can also do things like...

Session::set('mySessionVar', $myVal);
Log::warn('My warning message');


-Steve
andrew replied on at Permalink Reply
andrew
Yes, it has changed. No there currently isn't any documentation. ;) It's now based on the Symfony2 Event Dispatcher component, which gives us many nice things like the ability to prevent event bubbling, the ability to pass event data between multiple subscribers of an event, etc...

And no, the super user isn't in the administrator group. The administrator group is a group just like any other – it just happens to have lots of permissions set to it during installation. The super user is a special user – we check its ID during permissions checks and ignore permissions if you're user 1. That way you can't set up permissions in sucha way to accidentally exclude yourself – you can always fall back to the super user.
Shotster replied on at Permalink Reply
Shotster
> The administrator group is a group just like any other...

This was a point of confusion for me for quite some time after I started using C5, and I suspect it's potentially confusing to other newcomers to have a super user with a username that's an abbreviated version of the name of the group that's created by default. I'm wondering if it might make sense to change the name of the default group to "Site Editors" or some such.

-Steve
Shotster replied on at Permalink Reply
Shotster
> I'm wondering if it might make sense to change the name of the
> default group to "Site Editors" or some such.

I just realized you can change the user name of the admin user to something else, so perhaps this isn't as big a deal as I thought. Still, it might make sense to avoid confusion from the outset.

-Steve
TheRealSean replied on at Permalink Reply
TheRealSean
It is still possible to delete your user account as a "Super User" though? which could leave you in a sticky situation