excessive / DOMy

A DOM-like GUI framework for the *awesome* LÖVE framework
Other
32 stars 2 forks source link

Finding the elements #11

Closed pablomayobre closed 9 years ago

pablomayobre commented 9 years ago

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

karai17 commented 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
pablomayobre commented 9 years ago

That filtering will be raher expensive when looking up all the tables and then looking up that table and so on wont it?

karai17 commented 9 years ago

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?

pablomayobre commented 9 years ago

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

karai17 commented 9 years ago

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.

pablomayobre commented 9 years ago

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

karai17 commented 9 years ago

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" ...)
pablomayobre commented 9 years ago

Yeah sure! Just pointing a possibility there

karai17 commented 9 years ago

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)