Closed pablomayobre closed 9 years ago
Every single element will be in one large element table. This will allow us to quickly look through a table using the get_element_by_id function.
Each element will have a parent variable, a siblings table, and a children table. The contents of those tables will be pointers to the objects. This will allow us to grab a single element and then have access to its entire family.
There should also be filter functions which takes in a list of elements and returns a filtered list
local element = dom:get_element_by_id("some_element")
local c_filtered = dom:filter_elements_by_class(element.children, "class1", "class2", "class3", ...)
local t_filtered = dom:filter_elements_by_type(element.children, "button")
local child = element:get_child(3)
local parent = element:get_parent()
local g_parent = parent:get_parent()
local gg_parent = g_parent:get_parent()
local f_sibling = element:get_first_sibling()
local l_sibling = element:get_last_sibling()
-- et cetera
That filtering will be raher expensive when looking up all the tables and then looking up that table and so on wont it?
The initial grabbing of the element (by id) will be the most expensive since it has the largest table to look through. If you have 10 lists, each with 100 children, then the main element table will have 1000 elements to dig through whereas the filters only have 100 to dig through.
I don't believe it would be too expensive or slow, but I may be wrong. Perhaps @slime73 would like to comment?
In CSS I dont usually use ids, I tend to use classes for almost everything. If you filtr too many times I guess it can get expensive... not sure either
Right, but right now we aren't talking CSS so much as JavaScript. To get a handle on a particular element, we need to know its ID. From there, we can access that element's entire family to do with as we please.
Well it is the same I think, I was saying that I dont use ids to identify elements, I filter them because in most cases I have various items that do roughly the same thing
Well, you COULD go through every single element and filter them that way, but it is often useful to grab a handle on some subset, such as a character window or hotkey frame.
local filter = dom:filter_elements_by_class(dom.elements, "class1", "class2" ...)
Yeah sure! Just pointing a possibility there
The following selectors are now in place and can be used to filter results. If the elements argument is nil, it will default to the master element list:
gui:get_element_by_id(id)
gui:get_elements_by_type(type, elements)
gui:get_elements_by_class(class, elements)
As we discussed in issue #8 and #4 a problem is getting the elements that should be modified.
How should be the lookup tables be structured? How can we get an element filtered by id and classes and type and node.... etc.
This algorithm should also be efficient