Setting nested table keys dynamically (don't know how to call it)

[Wurstmann]

Hello!

What i'm trying to do is, create different options for my addon for many different elements and AceDB should store those options in a variable looking something like this:

options = {
  showInCombat = true,
  icons = {
    width = 20,
    height = 20,
  },
  bars = {
    width = 200,
    height = 30,
    bar1 = {
      color = "green",
    },
    bar2 = {
      color = "red",
    },
  },
}

but currently it still looks like this:

options = {
  showInCombat = true,
  iconWidth = 20,
  iconHeight = 20,
  barWidth = 200,
  barHeight = 30,
  bar1Color = "green",
  bar2Color = "red",
}

Right now i have following 'set' (AceConfig) function:

function addon:SetSliderValue(info, value)
	local key = info[#info];

	db[key] = value;
end

"key" would be something like bar1Color, barWidth and so on, the variable name that will be filled with the value that got changed.
But i think it would look better and be more organized if all the options for the specific elements would be grouped together in nested tables.
My problem is, i don't know how to rewrite the 'set' function to do that.
I need something like this:

function addon:SetSliderValue(info, value)
	local rootNode = info[1]; -- "bar"
	local secondNode = info[2]; -- "bar1";
	local thirdNode = info[3]; -- "color";

	-- db[rootNode][secondNode][thirdNode] = value;
	-- db.rootNode.secondNode.thirdNode = value;

end

And this part is where i don't know how to do it.
I searched on google but didn't really know what to search for, so came up with nothing related to my problem.
Is this somehow possible? Is this even a good idea?
Or should i create a new function for every "layer", db.bars[key] = value, db.bars.bar1[key] = value and so on?
But one function would be so much simpler to maintain... :O

[Xrystal]

I'm pretty sure I have that type of thing in one of my addons on my desktop. When I get back home after the weekend I'll take a look if no one has replied by then.

[Wurstmann]

Ok after some more testing and trying i think i figured it out

if(#info > 1) then                         -- if it has 'child nodes'
	local writeTo = db[info[1]];    -- set it to the root node
	
	for i=2, #info-1 do                    -- for every child node
		writeTo = writeTo[info[i]];   -- go one step deeper into the 'tree'
	end
	
	writeTo[info[#info]] = value;       -- set the last node to the value
else                                           -- it doesn't have child nodes
	db[info[1]] = value;             -- just set it normally
end

I guess it works because by assigning an existing table (in this case the database with all the options) to 'writeTo' the variable doesn't get a copy of the table, but a reference to it, something similar to a pointer in C with the memory adress like {ff0e0394} (i'm not a c programmer so correct me if im wrong). And when we assign a value to a key in writeTo, the ACTUAL table gets modified.
Something like that...
But maybe theres something simpler than that, so if you know it, let me know

Edit: now cleaner simpler code!

local writeTo = db;

for i=1, #info-1 do
	writeTo = writeTo[info[i]];
end

writeTo[info[#info]] = value;

[SDPhantom]

It would be an easy thing to do with metatables.

local table=setmetatable({},{__index=function(t,k)
	t[k]=setmetatable({},getmetatable(t));
	return t[k];
end});

- or -

local table={};
setmetatable(table,{__index=function(t,k)
	t[k]=setmetatable({},getmetatable(t));
	return t[k];
end});

Here's how it works. The __index metamethod is called/used when the index doesn't exist. This can be a function to deal with it or another table to grab values from. The value returned from the function is passed back as the value for the associated key. When a table is provided, it looks up the key in the table and returns its value.

In this case, we have a function to create a new table and propagate itself to it. The first line creates the table and sets it to the key provided. The second line returns the table after it has been set. The return is still required even though the value is now set.



If the table is not empty when the metatable is set, it will not apply to any existing table values. To do this, I'll post some experimental code that'll handle this. Just put this somewhere and call CreateDynamicStructure() on the table. It works recursively without increasing the call stack any further than needed.

do
    local meta;--   This value prototype will allow propagation
    meta={__index=function(t,k)
        t[k]=setmetatable({},meta);
        return t[k];
    end};
 
    local buffer={};
    function CreateDynamicStructure(tbl)
        table.insert(buffer,tbl);
        while #buffer>0 do
            local val=buffer[1];
            for i,j in pairs(val) do
                if type(j)=="table" then
                    table.insert(buffer,j);
                end
            end
            setmetatable(val,meta);
            table.remove(buffer,1);
        end
        return tbl;
    end
end