[Request]LibConstantProvider
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:
Lua Code:
Code:
localization/$(language).lua 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"? |
If I understand you correctly, there's no need for a separate library, LibStub is enough.
Lua Code:
Lua Code:
|
Quote:
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. |
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.
|
Quote:
@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). |
Quote:
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? |
It's still stored in that table.
|
Quote:
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. |
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. Code:
## Title: Do Someting Interesting Addon First lines or so of IAddon.lua. Code:
MyAddon = { Now in IAddonExternalDataFile.lua you reference the single table of your addon. Code:
MyAddon.UI = {
Placing MyAddonStringList$(language).lua and MyAddonMethods$(language).lua in the manifest would load two files. --Helja |
All times are GMT -6. The time now is 10:57 AM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2014 - 2022 MMOUI