Coding Standard Proposal
Coding Standard Proposal
Since we coders all use item.TAG sooner or later, somehow. I think we need a non interfering way to set it for our purpose
Here’s my proposal :
var cnf = JSON.parse(item.getTag())||{};
if( !(“SaveClr” in cnf)) {cnf.SaveClr = {};}
cnf.SaveClr.BG = px;
cnf.SaveClr.FG = pxtx;
item.setTag(JSON.stringify(cnf));
]]>
D5 Creation
< ![CDATA[
Any comments / recommandation from Pierre Hébert TrianguloY or Lukas Morawietz ??
]]>
< ![CDATA[
What about a item.getTag(id) and item.setTag(tag,id)
where id is a string representing the name of the var you want to get?
It will be useful to have this from launcher side, but will be also possible from script side, defining those functions at the beginning.
If ‘id’ is null it will just behave as usual. This won’t break previous scripts, and won’t interfere each other if you choose good names for those ids.
This will also help storing multiple variables in the tag without worrying to use JSON (even thought will be used internally in those functions)
Note: the code of those functions will be the one you posted with little modifications.
]]>
< ![CDATA[
If I understand right, your suggestion would be a feature request. Where my code has json-hassel, but is for current.
But this feature sounds easier.
]]>
< ![CDATA[
TrianguloY’s suggestion has another advantage: one old Script could run parallel without breaking stuff. In your suggestion would one old Script break every other script, even if these use ur method.
In conclusion TrianguloY’s way would give a script almost security to run without interference, while yours doesn’t.
I hope Pierre Hébert will implement this.
]]>
< ![CDATA[
That would imply to have an enumerator too, something like getAllTagIds().
]]>
< ![CDATA[
Not necessarily.
The use is that a script can not know all ID’s, but only the one the dev has the ID for. So scripts won’t interfere, and shouldn’t be able to.
]]>
< ![CDATA[
This is needed for cleanup, in order to avoid tags to remain there, hidden after use.
]]>
< ![CDATA[
I am rereading TrianguloY ‘s post and I understand now what you mean with script side. (I was in a hurry while reading the discussion previously).
I don’t think this can be done through script because it would still use the same tag and the same data under. Any script not using this method would break other scripts because this remains a convention.
The only way is to implement this on the launcher side and store data in different locations in a map id->data.
]]>
< ![CDATA[
I have two questions:
– is it needed to handle an id for Script and Container objects too ? (I would say: yes)
– if so, does it hurt if the tag for containers and scripts are lost during the update ? (I hope no)
]]>
< ![CDATA[
1) yes 2) update? To a new LLX version, you mean?
]]>
< ![CDATA[
Yes, when updating from b3 to b4 probably.
]]>