{"action":"created","issue":{"url":"https://api.github.com/repos/winder/Universal-G-Code-Sender/issues/1076","repository_url":"https://api.github.com/repos/winder/Universal-G-Code-Sender","labels_url":"https://api.github.com/repos/winder/Universal-G-Code-Sender/issues/1076/labels{/name}","comments_url":"https://api.github.com/repos/winder/Universal-G-Code-Sender/issues/1076/comments","events_url":"https://api.github.com/repos/winder/Universal-G-Code-Sender/issues/1076/events","html_url":"https://github.com/winder/Universal-G-Code-Sender/pull/1076","id":339830112,"node_id":"MDExOlB1bGxSZXF1ZXN0MjAwMzg2NzE1","number":1076,"title":"Add homing cycle for g2core XYZ axes","user":{"login":"justinclift","id":406299,"node_id":"MDQ6VXNlcjQwNjI5OQ==","avatar_url":"https://avatars2.githubusercontent.com/u/406299?v=4","gravatar_id":"","url":"https://api.github.com/users/justinclift","html_url":"https://github.com/justinclift","followers_url":"https://api.github.com/users/justinclift/followers","following_url":"https://api.github.com/users/justinclift/following{/other_user}","gists_url":"https://api.github.com/users/justinclift/gists{/gist_id}","starred_url":"https://api.github.com/users/justinclift/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/justinclift/subscriptions","organizations_url":"https://api.github.com/users/justinclift/orgs","repos_url":"https://api.github.com/users/justinclift/repos","events_url":"https://api.github.com/users/justinclift/events{/privacy}","received_events_url":"https://api.github.com/users/justinclift/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":10,"created_at":"2018-07-10T12:56:24Z","updated_at":"2018-07-15T16:45:55Z","closed_at":"2018-07-11T05:13:40Z","author_association":"CONTRIBUTOR","pull_request":{"url":"https://api.github.com/repos/winder/Universal-G-Code-Sender/pulls/1076","html_url":"https://github.com/winder/Universal-G-Code-Sender/pull/1076","diff_url":"https://github.com/winder/Universal-G-Code-Sender/pull/1076.diff","patch_url":"https://github.com/winder/Universal-G-Code-Sender/pull/1076.patch"},"body":"Adds homing to TinyG/g2core as described in #1071"},"comment":{"url":"https://api.github.com/repos/winder/Universal-G-Code-Sender/issues/comments/405103364","html_url":"https://github.com/winder/Universal-G-Code-Sender/pull/1076#issuecomment-405103364","issue_url":"https://api.github.com/repos/winder/Universal-G-Code-Sender/issues/1076","id":405103364,"node_id":"MDEyOklzc3VlQ29tbWVudDQwNTEwMzM2NA==","user":{"login":"breiler","id":8962024,"node_id":"MDQ6VXNlcjg5NjIwMjQ=","avatar_url":"https://avatars0.githubusercontent.com/u/8962024?v=4","gravatar_id":"","url":"https://api.github.com/users/breiler","html_url":"https://github.com/breiler","followers_url":"https://api.github.com/users/breiler/followers","following_url":"https://api.github.com/users/breiler/following{/other_user}","gists_url":"https://api.github.com/users/breiler/gists{/gist_id}","starred_url":"https://api.github.com/users/breiler/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/breiler/subscriptions","organizations_url":"https://api.github.com/users/breiler/orgs","repos_url":"https://api.github.com/users/breiler/repos","events_url":"https://api.github.com/users/breiler/events{/privacy}","received_events_url":"https://api.github.com/users/breiler/received_events","type":"User","site_admin":false},"created_at":"2018-07-15T16:45:55Z","updated_at":"2018-07-15T16:45:55Z","author_association":"COLLABORATOR","body":"@winder regarding experiences implementing support for a new controller. \r\n\r\nIt's pretty straight forward to implement a controller when you know what happens in the lower layers. For instance the `AbstractController` uses a **template method** design pattern which usually requires the implementor to know a little about when and where the method is called from the lower layers. I think that this is fine as it is today, but could be improved with some javadoc. The most tricky part to implement was figuring out which events should be triggered and when. The actions weren't difficult to implement at all as the contract/interface for these are well defined.\r\n\r\n> Remove the \"actions\" from the controller interface and replace them with runtime annotations. They can use something like the Overrides enum or the CapabilitiesConstant to tag specific methods like @UGSCapability(HOMING).\r\n\r\nI'm not sure about this. Is this going to work with methods requiring different number of parameters. How will the implementors know what those are without a well defined contract?\r\n\r\n> Move the \"action\" logic into the capabilities, and have some sort of capabilities processor (whether it be a new service, a method in BackendAPI or AbstractController). The processor can then first call grblCapabilities.hasCapability(X), and if it is available it can then call grblCapability.performAction(X). We would probably want to convert CapabilitiesConstants into an enum for this to work.\r\n\r\nI made the Capabilities as an enum at first but thought that one of the feedback you had made sense. Some controllers may have internal capabilities such as in the ```GrblCapabilitiesConstants``` which is a pretty convenient way to \"feature toggle\" different parts of the controller.\r\n\r\nI do like the idea of a service which is called from a processor. This would make the controller implementation a bit smaller and more clean.\r\n\r\n> Remove the \"action\" logic from Capabilities and let them exist as they do today in the Controller, perhaps with new canHome style methods.\r\n\r\nI'm thinking that a capability could theoretically be used to hide a homing button when a controller doesn't have that function. But a \"canHome\" method could be misinterpreted by the developer that the function is/isn't available at a given time, i.e. when running a gcode file."}}
{"actor":{"display_login":"breiler"}}