local mainName = GetMainName("SomeAlt")
local alts = { GetAltNames("SomeMain") }
Now you maintain your own SVs, and you can have multiple addons providing data, and the API is lolminimal.
An implementation would be something along the lines of:
local oldGetMainName = GetMainName or function() return end
function GetMainName(name)
if myAddon.db.chars[name] and myAddon.db.chars[name].main then
return myAddon.db.chars[name].main
else
return oldGetMainName(name)
end
end
Tadaa?
(Note "return" vs "return nil", which becomes important for alt names. "return nil" = 1 entry with nil in it. "return" = 0 values.)
Edit: Oh, and addons both providing and displaying main/alt data, e.g. Prat/Chatter, should of course call GetMainName() themselves, not only look in their own SVs.
Prat's already has an option to use the data from libalts
-- function for showing main names in the tooltip
function module:getMain(altname)
if self.db.profile.usealtlib then
local main = altregistry:GetMain(altname)
if main then
return self:formatCharName(main)
end
return false
end
-- check a main exists for the given alt name
if not self.Alts[altname] then return false end
return self.Alts[altname]
end
and publish its data
-- Load shared Alts data
for alt,main in pairs(self.db.realm.alts) do
altregistry:SetAlt(main,alt)
end
Now you maintain your own SVs, and you can have multiple addons providing data, and the API is lolminimal.
Thats how it works already - whats wrong with the way it is?
How would you manage the data with Mikk's idea? It sounds like addons would only have control over their own pool of alt data, and that you could end up with a huge cluttered mess.
It works fine for item prices, since there's only one price per item, but what happens if, say, a guildmate changes mains?
Absolutely true... but I don't see how LibAlts solves that either? (Maybe I'm missing something; entirely possible)
Libalts doesnt do anything besides provide an abstract data layer which decouples producers and consumers. An change in an alt would probably not be fully picked up until the next reload ui.
Libalts doesnt do anything besides provide an abstract data layer which decouples producers and consumers. An change in an alt would probably not be fully picked up until the next reload ui.
This is why I proposed the UnSet Alt Function with a callback handler. The callback could be used for all addons to update their data when the callback is fired. :cool: This would keep all the data in "synch" without needing a ui relaod.
This is why I proposed the UnSet Alt Function with a callback handler. The callback could be used for all addons to update their data when the callback is fired. :cool: This would keep all the data in "synch" without needing a ui relaod.
Interesting idea - only thing is that the data could be stored by multiple addons. Its best to use just one to load the alt data.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Prat's already has an option to use the data from libalts
and publish its data
Thats how it works already - whats wrong with the way it is?
My version uses less memory and doesn't require a library? :p
Edit: Oh, and moves the CPU load to on-demand bit-by-bit as-needed and not a full copy every time you load the UI.
I can probably think of more if I really try :D
It works fine for item prices, since there's only one price per item, but what happens if, say, a guildmate changes mains?
Libalts doesnt do anything besides provide an abstract data layer which decouples producers and consumers. An change in an alt would probably not be fully picked up until the next reload ui.
This is why I proposed the UnSet Alt Function with a callback handler. The callback could be used for all addons to update their data when the callback is fired. :cool: This would keep all the data in "synch" without needing a ui relaod.
Interesting idea - only thing is that the data could be stored by multiple addons. Its best to use just one to load the alt data.