# Refactoring the Event module (or not)

**URL:** <https://talk.openmrs.org/t/refactoring-the-event-module-or-not/17281>\
**Category:** Development\
**Created:** [April 1, 2018, 4:18am UTC](https://talk.openmrs.org/t/refactoring-the-event-module-or-not/17281 "2018-04-01T04:18:03Z")\
**Posts on this page:** 1\
**Showing post:** 7

<div class="post-metadata">

**Author:** ![darius](https://talk.openmrs.org/user_avatar/talk.openmrs.org/darius/32/8082_2.png) [@darius](https://talk.openmrs.org/u/darius)\
**Post date:** [April 4, 2018, 11:42pm UTC](https://talk.openmrs.org/t/refactoring-the-event-module-or-not/17281/7 "2018-04-04T23:42:09Z")

</div>

> [@mseaton](#):
>
> Will the atomfeed module just have an Interceptor that is concerned with it’s own use case (recording an entry on the feed), or will the atom feed module also contain the code needed to subscribe to events with a callback that can be executed within the current transaction?

I was expecting the following:

_Near Future State_

- atomfeed has an interceptor only concerned with its own use case, with minor changes per Wyclif
- event module stays as-is (i.e. keeps it own interceptor)
- openmrs-core introduces a new callback-on-db-change API, but this is only available from 2.2.0.

_Later_

- we have a module like “callbackondbchange” which is a compatibility module providing this functionality for versions of openmrs core \< 2.2.0
- atomfeed is aware-of callbackondbchange, and will conditionally use either openmrs-core or this
- even module is aware-of callbackondbchange, and will conditionally use either openmrs-core or this

Now that I have written this, it seems like it actually makes sense to write the callbackondbchange module _first_ and then move its code to openmrs-core after some testing.

(Mike I think you’re suggesting that we should just put this new API in atomfeed for now to avoid having yet another module and because atomfeed seems to be becoming a recommended module. I understand that motivation but I’d still vote for putting in in a single clean module, that will no longer be required after the next core release.)

Also, note that the Event API is actually based on JMS, and we wouldn’t actually want this exact API for the “callbacks within hibernate interceptor” module.

---

_[View the full topic](https://talk.openmrs.org/t/refactoring-the-event-module-or-not/17281)._