{"action":"opened","issue":{"url":"https://api.github.com/repos/sirinsidiator/ESO-LibAddonMenu/issues/8","labels_url":"https://api.github.com/repos/sirinsidiator/ESO-LibAddonMenu/issues/8/labels{/name}","comments_url":"https://api.github.com/repos/sirinsidiator/ESO-LibAddonMenu/issues/8/comments","events_url":"https://api.github.com/repos/sirinsidiator/ESO-LibAddonMenu/issues/8/events","html_url":"https://github.com/sirinsidiator/ESO-LibAddonMenu/issues/8","id":58224499,"number":8,"title":"LAMCreateControl and common widget functionality","user":{"login":"merlight","id":8362838,"avatar_url":"https://avatars.githubusercontent.com/u/8362838?v=3","gravatar_id":"","url":"https://api.github.com/users/merlight","html_url":"https://github.com/merlight","followers_url":"https://api.github.com/users/merlight/followers","following_url":"https://api.github.com/users/merlight/following{/other_user}","gists_url":"https://api.github.com/users/merlight/gists{/gist_id}","starred_url":"https://api.github.com/users/merlight/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/merlight/subscriptions","organizations_url":"https://api.github.com/users/merlight/orgs","repos_url":"https://api.github.com/users/merlight/repos","events_url":"https://api.github.com/users/merlight/events{/privacy}","received_events_url":"https://api.github.com/users/merlight/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2015-02-19T15:41:11Z","updated_at":"2015-02-19T15:41:11Z","closed_at":null,"body":"```lua\r\n-- this is not a code sample, you're supposed to execute this right now in your head ^^\r\nlocal LAMCC = LAMCreateControl\r\n```\r\n\r\nLAMCC is the namespace containing widget constructors.\r\nIt is also used to hold counters for generating unique control names. While convenient, this is where namespace pollution starts. Recently we started seeing opportunities to extract some common widget-constructor code, and LAMCC looks like it might contain that. But it could quickly become a mess.\r\n\r\nSo here's my suggestion to keep LAMCC clean (widget constructors only) while having some place to share code across widgets.\r\n\r\nMake LAM:RegisterWidget return a widgetClass table or nil. Similar to how LibStub works, 100% backwards compatible. The widgetClass will have its metatable set to a SHARED namespace. Although the SHARED namespace together with the widgetClass directory could be local in the main Lua file, I'm inclined to put them in a separate file, so that'd be two more LAM polluters.\r\n\r\nWidget files will then look like this:\r\n```lua\r\nlocal widgetVersion = 9\r\nlocal LAM = LibStub(\"LibAddonMenu-2.0\")\r\nlocal PANEL = LAM:RegisterWidget(\"panel\", widgetVersion)\r\nif not PANEL then return end\r\n\r\n-- now PANEL is this widget's private namespace,\r\n-- it can put anything it wants in there, and can also\r\n-- use functions defined in COMMON namespace, like:\r\nlocal buttonId = PANEL:GetNextControlId(\"button\")\r\n```\r\n\r\nThe current method of defining the constructor will be kept for the sake of compatibility...\r\n```lua\r\nfunction LAMCreateControl.panel(parent, panelData, controlName)\r\n```\r\n... but if we only allow widget constructors in LAMCC, we can add a sanity check:\r\n\r\n```lua\r\nsetmetatable(LAMCC, {\r\n    __newindex = function(self, key, val)\r\n        if not LAM.widgets[key] then\r\n            error(\"defining constructor without registering the widget first, maybe a typo?\")\r\n        else\r\n            rawset(self, key, val)\r\n        end\r\n    end\r\n})\r\n```\r\n\r\nWhat do you think?\r\n"}}