Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestion: Multi-Event subscribers #1735

tfenster opened this issue Mar 5, 2018 · 2 comments


None yet
3 participants
Copy link

commented Mar 5, 2018

I personally think the event subscription idea is nice but sometimes not covering enough. Especially when we in the future might talk about extensions extending other extensions with no source access, it will become very difficult to know which events need to be subscribed to. Might it be an idea to do “multi-event subscribers” where if you want to subscribe to an event you also need to subscribe to others? E.g. if someone wants to handle an event on posting some custom entity my extension adds, I want to ask them to also handle canceling it. The subscribers would still be able to do nothing but at least they would know what I expect them to do.

I have an idea how this could be built but first, is this something that makes sense to you and you would consider?


This comment has been minimized.

Copy link

commented Mar 5, 2018

You're thinking about something like object-oriented interfaces. The idea sounds interesting. Basically, then you could have something like posting routine event provider, which would, let's say define 3 events (just for the sake of example):

  • OnPostDocument
  • OnInitLedgerEntry
  • OnTransferJournalLineToLedgerEntry.
    Any subscriber that chooses to consume one of the events, would need to consume the other two as well, thus "implementing the interface".

Sounds interesting in theory, but might be a bit over-complicated. Let's see what the team thinks.


This comment has been minimized.

Copy link
Contributor Author

commented Mar 5, 2018

Absolutely, but "how about implementing object-oriented concept x" has generated some push-back in the past, so I tried to describe it more along already existing NAV / AL concepts :) And yes, it is a bit more complex than the current event paradigm but I personally think that in the future we'll see more complex dev scenarios in NAV / D365 (like extensions extending other extension) and that calls for more complex dev paradigms being supported. But if there are simple solutions for that, I am happy to use those, I just don't see any

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.