This repository has been archived by the owner on Jun 30, 2022. It is now read-only.
User-controlled routing #100
Comments
|
I don't know whether or not it's the best way, but Hubot accomplishes doing this with an alias module: https://github.com/ohjames/hubot-scripts/blob/master/alias.coffee It's not powerful enough to address all needs, but it gets a big chunk of them. |
jimmycuadra
added
component/handlers
effort/hard
type/feature
status/accepted
and removed
enhancement
labels
|
I think having this built into core would be awesome, however we have been happy with the plugin (confession: I've done some work to make it on par with the hubot one). https://github.com/apsoto/lita-alias |
glittershark
added a commit
to glittershark/lita
that referenced
this issue
Feb 1, 2016
Add support for passing a Proc to routes instead of a regular expression for matching - this proc will then be called with the message in the context of the handler object and should return a boolean indicating whether the route matches or not. This allows for dynamically defined routing, plus support for configuring things like command names and prefixes, which is useful as plugin configuration is only available on a handler instance, not the singleton. Probably addresses most of what litaio#100 is asking for
glittershark
added a commit
to glittershark/lita
that referenced
this issue
Feb 1, 2016
Add support for passing a Proc to routes instead of a regular expression for matching - this proc will then be called with the message in the context of the handler object and should return a boolean indicating whether the route matches or not. This allows for dynamically defined routing, plus support for configuring things like command names and prefixes, which is useful as plugin configuration is only available on a handler instance, not the singleton. Probably addresses most of what litaio#100 is asking for
glittershark
added a commit
to glittershark/lita
that referenced
this issue
Feb 1, 2016
Add support for passing a Proc to routes instead of a regular expression for matching - this proc will then be called with the message in the context of the handler object and should return a boolean indicating whether the route matches or not. This allows for dynamically defined routing, plus support for configuring things like command names and prefixes, which is useful as plugin configuration is only available on a handler instance, not the singleton. Probably addresses most of what litaio#100 is asking for
glittershark
added a commit
to glittershark/lita
that referenced
this issue
Feb 1, 2016
Add support for passing a Proc to routes instead of a regular expression for matching - this proc will then be called with the message in the context of the handler object and should return a boolean indicating whether the route matches or not. This allows for dynamically defined routing, plus support for configuring things like command names and prefixes, which is useful as plugin configuration is only available on a handler instance, not the singleton. Probably addresses most of what litaio#100 is asking for
glittershark
added a commit
to glittershark/lita
that referenced
this issue
Feb 1, 2016
Add support for passing a Proc to routes instead of a regular expression for matching - this proc will then be called with the message in the context of the handler object and should return a boolean indicating whether the route matches or not. This allows for dynamically defined routing, plus support for configuring things like command names and prefixes, which is useful as plugin configuration is only available on a handler instance, not the singleton. Probably addresses most of what litaio#100 is asking for
glittershark
added a commit
to glittershark/lita
that referenced
this issue
Feb 1, 2016
Add support for passing a Proc to routes instead of a regular expression for matching - this proc will then be called with the message in the context of the handler object and should return a boolean indicating whether the route matches or not. This allows for dynamically defined routing, plus support for configuring things like command names and prefixes, which is useful as plugin configuration is only available on a handler instance, not the singleton. Probably addresses most of what litaio#100 is asking for
glittershark
added a commit
to glittershark/lita
that referenced
this issue
Feb 1, 2016
Add support for passing a Proc to routes instead of a regular expression for matching - this proc will then be called with the message in the context of the handler object and should return a boolean indicating whether the route matches or not. This allows for dynamically defined routing, plus support for configuring things like command names and prefixes, which is useful as plugin configuration is only available on a handler instance, not the singleton. Probably addresses most of what litaio#100 is asking for
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
To maximize user control and the utility of open source plugins, there should be a way for users to declare custom routes that invoke particular functionality in a plugin. The user should be able to use aliases for messages/commands that they prefer, and controller authorization group restrictions, etc. beyond what the plugin author has provided.
The text was updated successfully, but these errors were encountered: