Event plugin with sidebar companion

[kidgoo]

Hey all...

I was wondering if there's an established "right" way to have an event plugin with a sidebar companion that can, in a perfect world, access the event's functions...

Thanks,
Brett

[mgroeninger]

The way I did it in serendipity_event_linklist is to define event hooks in the event plugin and have the sidebar plugin call them.

Plugins like serendipity_event_mycalendar simply do a database query against the same table that the event plugin uses.

I'm not sure if there is a prefered method though. Perhaps Garvin or someone else knows the best way to do it (though Garvin wrote mycalendar, so I would bet that is a good way).

I'd say if you can use event hooks to enable code reusage that would be nice. Otherwise it might be overkill.

[kidgoo]

I did have a look at mycalendar, and it looks like the two are just sharing tables, but it's simple enough for that to be effective...

I also thought about using event hooks called from the sidebar, but it felt kinda hacky for what I was doing. I think I've decided to export the functions to an include file, and include it in both the event and plugin files. Would this be the overkill you spoke of?

[mgroeninger]

I don't think that would be overkill. If the two plugins will share a lot of code I think that makes good sense.
You should probably ask Garvin, though, or drop a note to the developers email list if you want more input.

[garvinhicking]

When sharing functions accross plugins, I also tend to use a "common.inc.php" file like within the plugin_loginform plugin. Those then share common classes/functions.

Apart from that, it's recommended to have plugin-related table slike the calendar plugin where you can share data.

In the past few months I've come to the conclusion that polluting the plugin propbag ($this->get_config(...)) container is not the wisest way to store many properties, as they get loaded on each request and are put in the $serendipity superarray. So the less you need to access via those means, the faster. That's the way why we no longer store the staticpages in a ->set_config container, as it would really eat up some memory on large pages.

Regards,
Garvin