Event listeners
asdf
- elm.addEventListener("event", handler);
- elm.removeEventListener("event", handler);
what does the true/false as 3rd argument
anonymous functions:
''The main advantage I find is that because it's declared inline, the anonymous function has access to all the current local variables within scope which can vastly simplify your code in some circumstances. A classic example is with setTimeout() where you want it to operate using variables defined in the scope above.''
''Of course, an anonymous function also doesn't interfere with whatever namespace you're in (global, local within the function, etc...) since it doesn't need a name.''
''A disadvantage of using an anonymous function with an addEventListener(type, fn) event handler is that you can't remove just that event listener because you don't have a handle on the function.''
''Another disadvantage of anonymous functions is that a new function is created every time the code that uses it runs, which in some cases makes no difference at all, but in other cases may be something to consider for performance reasons (e.g., if doing things in a loop)''
asdf
Removing event listeners, beware of creating function within the code, it creates a new instance of the same function, so it won't get removed.
Subjects
I thought more about tags and found out it's even more flexible, than I imagined. All in the sense of the original idea of simplification for QetriX, tags is a generic group of anything.
It works well for users. Now tag is not only a group of users, but it acts as a role as well. You can tag users as “employee”, “customer”, “vip”
Tags! Tags everywhere!
I liked the idea for at least a decade: do not structure items into hierarchical categories, but assign them a bunch of tags and if needed, structure those tags into hierarchy.
Imagine a filesystem, where directories (folders) will be structured in a familiar tree structure, but you'd be able to assign them to files as tags. You'd copy a file simply by assigning another directory to the file and you'd be able to create a multitude of “virtual” directories to categorize the file.
Now I applied the idea on Qedy and upgraded tags to classifications. You do not specify a type of an entity, you assign it a bunch of tags to classify it. It's brilliant how elegantly it fits the whole concept.
The primary purpose is not filtering ''per-se'', but rather creating lists of similar entities. You can specify particular tags for a menu items, for similar articles, you can define binary flags as tags (paid, published) and more. Tags are great for multi-language projects, because they are translatable.
Working with tags is easy and straightforward, but as usual, the major drawback is performance. It's fast to find all entities with a given tag, it's still quite fast to find all entities with given tags, but it's database killer to find all entities with such and such tags, that are missing another set of tags.
Wikipedia categories are a great example of tags
For example, in CRM you might want to list all customers, who ordered stuff during past 6 months, but didn't add some service you offer, like insurance, gift wrap or personification. Of course you can define a tag “no-insurance”, but you could easily end up with thousands of tags and millions of tag assignments, because you never know what you'll need to query one day, which quickly becomes a nightmare to manage and expensive to store.
Another nice, but resource heavy use case is to find similar entities just by their tags. You simply compare entities by their tags and find closest matches. It's quite easy for those with the same amount of tags, but becomes difficult when the count differs. How related are entities “A” with tags [a,b,c,d] and “B” with tags [c,d,e]?
I kept returning to the idea of having just a sets of tags instead of enums, especially for states (in processes), but only after I finally implemented that I realized it's flawed, because tag is not a value, tag is an attribute. And to translate it to the value you must test every single one of them.
In programming terms, you can't do switch(state), you must do if(state1)-elseif(state2)-elseif(...). And you can't do return state, you must do return state1 || state2 || .... So if you have to specify every tag in the code, there's no point to have them dynamic.
You can use elem-elems, but that's very inefficient and makes database queries way too long. So it's only feasible to do it if the value is yes-no, tag is present or it's not present.