Added Enable/Disable hook for sprockets #73
Conversation
| @@ -502,5 +532,17 @@ private void Send(string command) | |||
| _chat.Invoke("send", command).Wait(); | |||
| } | |||
|
|
|||
| private void SetSprocketEnabled(string sprocketTypeName, bool enabled) | |||
There was a problem hiding this comment.
Do we want to use something simpler to identify sprockets than the full type? Someting like an int ID?
There was a problem hiding this comment.
The problem with that is that where would this ID live? I don't want to add it to the ISprocket interface thus forcing all implementers to arbitrarily return some random int.
There was a problem hiding this comment.
Not return a random int, but the host/bot should assign the ID when it is set up.
Idea: what if you wanted to create two sprockets in the same bot, but listening to different rooms. The architecture currently suggests only one will ever exist, but I'm trying to think of a use case where you might want to have multiple instances of the same sprocket being active...
Configuration is another topic I need to think about too (unrelated to all this).
There was a problem hiding this comment.
Right, but the ISprocket interface would still need an ID prop like int ID {get; set;}, and we'd have to make it very clear in the documentation that this is something you do NOT need to set when implementing a custom sprocket.
There was a problem hiding this comment.
After some more pondering, I don't think we need to clutter up the ISprocket interface with that detail.
Given the Bot maintains a collection of sprockets internally, perhaps switching IList<T> to IDictionary<T,K> is an easier change to manage.
Problem with heading down that path is that we need to handle sprockets and announcers in the same fashion.
i'm just jotting down notes as these things come to mind
There was a problem hiding this comment.
That thought crossed my mind as well, but then you'd need a way of exposing these ID's to the outside world, since the WebApp needs a way to build the urls to enable/disable the sprockets. Right now, in the IoC container we just have a list of Sprockets and that gets passed along in the HomeModule to the view. When looping through this collection and building the list of sprockets, we need a way to build the enable/disable url for each sprocket e.g. /bot/enable/{id}.
sorry to be a pain
There was a problem hiding this comment.
To decouple the model from the view, we should be using viewmodels to represent the structure of data on the screen. This may help us cover multiple issues:
- the Bot only tracks sprockets which are running
- inactive sprockets require an identifier too - so that we can create the "enable" URLs too
- the bot shouldn't care about the URL generation code
it's all good, i wish i had more time at the moment to code. is it friday yet?
|
The things I'm adding in #69 could be used for it |
|
OK, I like the name idea. How do I go about merging your changes into mine? I'm still new to Git... |
|
I had some issue with my commit and some lineend inconsistency, when I've added mine I'll send a pullrequest and then @shiftkey or one of the other will handle it, afterwards you can tune your stuff to use it. |
…ith ID logic moved to AspNetBotHost
|
I'm going to have to close this one - we've nearly got JibbR back to how it was, but still requires us to think about how it is hosted. |
|
Ping @cyberzed |
The ISprocket interface now has an Enabled property. In the Bot, this property is set to true when starting up. Whenever the bot is sent a message, while it's looping through the list of ISprockets, it checks this flag. The bot now also has Enable/Disable methods to enable/disable specific sprockets. For now it just takes in a string (ISprocket.GetType().FullName) as there's no easy way to identify a Sprocket (maybe we should add a "SprocketName" or something, food for thought....). I also updated the AspNetBotHost web app with Enable/Disable buttons on the Index page alongside the Sprockets listed.