[Request]LibConstantProvider

[zgrssd]

We can provide bulk data for our addons functionality in a seperate .lua file, by assigning the data to a global Variable in the .lua file. Something like this:

OurAddonConstants = {
  --insert really big table here
}

We are supposed to use this in particular for localisation (with the idea that the the proper languages .lua file is loaded based on client langauge and manifest entry):

localization/$(language).lua

On the plus side this allows us to split large amount of default data (like where each Skyshard/Lorebook can be found) over multile files.
On the downside this does pollute the global namespace with a lot of constants (at least 1 per addon; possible 1 more for Localisation uses). And if there is one thing I don't like it is a untidy global namespace.

LibStub allows us to share libraries across Addon barriers. It also ensures only the most current version is used. But very important for me it also keeps the global namespace clean - the only thing that is needed is the global variable that holds libStub itself. Via it you can request every library, wheter you provided it with your addon or it was installed stand alone.
LibMediaProvider does something similar for Media like Fonts, Textures and sounds (once they get implemented).

Would anybody be interested in writing such a library?
Could LibMedia Provider be expaneded for another read only type called "Lua Data"?

[merlight]

If I understand you correctly, there's no need for a separate library, LibStub is enough.

-- myaddondata.lua
local data = LibStub:NewLibrary("MyAddonData-1", 1)
if not data then return end
 
-- fill it ...

-- myaddon.lua, or someoneelsesaddon.lua, that wants to use myaddondata
local data = LibStub:GetLibrary("MyAddonData-1")

[zgrssd]

Originally Posted by merlight If I understand you correctly, there's no need for a separate library, LibStub is enough. -- myaddondata.lua local data = LibStub:NewLibrary("MyAddonData-1", 1) if not data then return end   -- fill it ... -- myaddon.lua, or someoneelsesaddon.lua, that wants to use myaddondata local data = LibStub:GetLibrary("MyAddonData-1")

That is an interesting solution and something I can work with.
However, I think this is not a longterm solution. While the lib Stub ID strings are a slightly less crowded area, there might still be colissions. And if we have colissions there we either loose some data or one of the libraries.

[merlight]

There might be collisions in any namespace. It depends only on how users of that namespace behave. If someone decides to publish their data under the name "Foo", or to hijack someone else's well-known identifier, no library can fix it. You could enforce something like tag:uri in a library, but I think anyone who doesn't enjoy shooting themselves in the foot, also doesn't name their globals Foo.

[Seerah]

Originally Posted by merlight If I understand you correctly, there's no need for a separate library, LibStub is enough. -- myaddondata.lua local data = LibStub:NewLibrary("MyAddonData-1", 1) if not data then return end   -- fill it ... -- myaddon.lua, or someoneelsesaddon.lua, that wants to use myaddondata local data = LibStub:GetLibrary("MyAddonData-1")

That is creating a library.


@zgrssd: LibMediaProvider is for media and media only. We won't be working localizations into there.

Libraries work best when specialized. Media (bar textures, fonts, etc.) is something that a user would want access to across all their addons that have options for those media types. General localization shouldn't be a library (settings names, etc.). Specific localization could be a library (locations or items).

[zgrssd]

Originally Posted by Seerah @zgrssd: LibMediaProvider is for media and media only. We won't be working localizations into there.

Localisation is just one minor side use for a "LibConstantProvider". Any bigger table/amount of data is worth being put into a seperate .lua file. Just that this would pollute the global namespace is preventing that.
Localisation is just one class of runtime constan data it could deal with.

I guess the biggest issue would be:
When upgrading to a higher library version, how do I preserve the data that was registered with the previous version?

[Seerah]

It's still stored in that table.

[zgrssd]

Originally Posted by Seerah It's still stored in that table.

After some thinking I think I get it now for libStub:
You create one table when a major library is first registered. You store all data into it using self.varname.
When upgrading the library or handing it out to consuming code, you just hand out the table again.

[Halja]

You can separate the data to many files if you want. The manifest order is important. Here is a general approach.
In the txt file.

## Title: Do Someting Interesting Addon
## Author: XXXXX
## Version: XXXX
## APIVersion: 100007
## SavedVariables: SomeSavedVariables

IAddon.lua
IAddonExternalDataFile.lua

First lines or so of IAddon.lua.

MyAddon = {
	Title = "Do Someting Interesting Addon",
	AnotherVar = "Derp!",
}

Now in IAddonExternalDataFile.lua you reference the single table of your addon.

MyAddon.UI = {
	["MainWindow"] = 
	{
		["WindowWidth"] = 305,
		["WindowHeight"] = 215,
	},
}

Your impact to the Global name space is the root table point. The cool thing about the localization variable is only the target language file is loaded. Even here you could leverage several files if you wanted too.

• MyAddonStringListEN.lua
• MyAddonStringListDE.lua
• MyAddonStringListFR.lua
  
• MyAddonMethodsEN.lua
• MyAddonMethodsDE.lua
• MyAddonMethodsFR.lua

Placing MyAddonStringList$(language).lua and MyAddonMethods$(language).lua in the manifest would load two files.
--Helja