ElmahR status, a new feature is enabling an interesting scenario
During the last few months I took a break from ElmahR, and I did not add any big new feature. I did some bug fixing and I added little things, but the last one I introduced in 1.1.0 is actually interesting, so I decided to talk a little bit about it.
It's been inspired by a feature request I received, and the resulting scenario is about connecting to an ElmahR dashboard which does not live under the same domain of the client code. The problem behind this is a well known one, and SignalR already handles it in a easy way to exploit. The problem with ElmahR was that I wasn't exposing that feature, but now with 1.1.0 you can specify if you want to enable cross domain requests by simply supplying a true
value to the Bootstrapper.PreBootstrap()
method, which must be called to startup the dashboard and it's usually called from the ElmahR.Core.cs
file placed in the App_Start
folder by the Nuget package.
With that support in place, it become fairly easy to connect the client-side ElmahR Javascript library to a dashboard living under a different domain. If you check out the ElmahR repository, you will find a new simple test web site called CORS, and the index.html page there will illustrate you how easily you can configure the library. The process is quite simple:
- configure the dashboard paths as it's done in the index.html sample, of course using your specific dashboard address
-
call
registerBuilder
, which expects an object defining method which extend theelmahr
global object; for example, if you want to receive errors notifications you'll need to redefine thenotifyErrors
callback; the code in index.html should be quite self explanatory - the new callback will be called at the right moment and each time you'll receive an array of errors which you'll be able to examine and manipulate
Everything described must be done when the DOM is ready. You can see which events are available on the client library looking at the source code here.
Finally, you might have noticed that the notifyErrors
callback is defined with an object containing a member called replacer
, this way we're instructing the elmahr
object to remove the default callback and use this new one. If you prefer, you can keep the default callback and just append yours, in this case it is enough to specify your callback directly as the value for the notifyErrors
member of the callbacks
object, without any intermediate object.
On the issue tracker there are a few more interesting suggestions, I'm currently thinking about them and I might do some work to implement them in the next few weeks.