How to get attributeValue of an attributeName svg element?
exp
<svg ..... fill:red......>
wen set attributeName -> fill I get red
What is your question?
Do you want to get a value...
Or set attributeValue...
In clear terms and some example code (if possible), please clarify.
get Value not Set
Control via messages
Most of the SVG information can be manipulated by sending input messages to this node.
Supported commands include...
- update_text
- update_innerHTML
- update_attribute
- set_attribute
- update_style
- set_style
so I need get_attribute command
{
"command": "get_attribute",
"selector": "#xxx",
"attributeName": "fill",
}
return msg.payload : red
Thank you, that is clearer.
This is not currently possible but it's something that could be considered.
Please raise an issue here and myself or @BartButenaers will consider it. Please include a link to this forum post in your GitHub issue.
1 Like
ok thanks to replay
Hi Steve (@d0d04m3),
I have closed the new (duplicate) issue, since somebody else already asked the same question last week: see this issue. But I don't see how we can build a reliable solution.
Summarized why I see a problem:
Suppose N of these floorplans are currently being displayed (where N can be zero). Indeed somebody can have multiple wall-mounted tablets in his house, so the floorplan might be visible at the same time N times. If you send a request to get the value of an element id, then you will get N responses. Where N can be 0 which means no response at all (e.g. when no dashboard is currently started or none of the dashboards is currently showing the tabsheet with the floorplan).
Summarized I can have duplicate output messages or no output message at all. Not sure how this can be of any practical use to anybody...
1 Like
And thats why I tagged you Bart 
I hadnt considered local (client side) animations that may have changed a style or attribute value of the DOM - I was considering node-red would query the SVG in the singular server-side (the single node-red ui-svg) node instance (obviously on thinking about this longer than 30s - i remember its client side once deployed). More in-depth than first glance!
@d0d04m3 I dont think this is going to happen anytime soon.
as a workaround I can only recommend you hold a context memory copy of what you set.
e.g. if you animate a circles fill to 'red' based on topic "lamp/status"''s payload, then store "lamp/status"''s payload in flow.context & when you need to know the value, you can retrieve the value from flow.context
2 Likes
thanks to replay
ok no problem
I make an array to store all current value of element but
I have more 100 element
and update this value when any value changed its hard
A lookup object is far easier (and faster) than an array.
e.g.
function code - Storing payload in flow context based on topic
let myStore = flow.get("myStore") || {};
myStore[msg.topic] = msg.payload;
flow.set("myStore", myStore )'
function code - getting value out of flow context based on topic
let myStore = flow.get("myStore") || {};
msg.payload = myStore[msg.topic];
return msg;
Thats it - no array to search, no hardcoding - works for storing & retrieving objects / arrays / numbers / strings
1 Like
its works
very thank
And that is why I tagged you Steve 
-
I was indeed thinking about getting all the information from the client-side DOM tree:
The advantage is that you get the correct values. But you get N values (so N output messages) because there are N svg drawings visible at the moment. Where N can be zero...
-
But like you say, the information could also be get on the server-side. Something like this I assume:
The advantage is that there is always 1 output message with the data.
But I think a lot of things should be implemented:- A DOM tree should be available on the server-side. Think we could use e.g. npm package @svgdotjs/svg.js, which allows the SVG string to be imported.
- But this also means that this server-side DOM tree should be always in sync with the server side DOM tree(s). So when an input message will be injected (e.g. to change an attribute value of an element), then the server side DOM tree should also be updated. So the whole message handling stuff should be moved to a js file, to make sure the same function can be used on both client and server side (and we just need to pass the correct dom tree instance as input for that function).
And then indeed there is also the problem of the animated values. But I think we can use the animVal instead of the baseVal for animated attributes??
Anyway seems quite some work to me. Although I understand that it could be useful...
Any thoughts?
1 Like
Yes, put it on the back burner 
Its a can of worms Bart 
1 Like
Hey,
I wasn't aware that your nickname was "The backburner" ... 
2 Likes
I have some trouble with the last solve
when update something in server-side and deploy node-red
all context still in memory
but SVG reset all value of element
and cant turn "on" again it's deactivated
because data value not equal between context and SVG
so when received new data and check it into context its found
but in your SVG not real existing
so it forces me to wait for next incoming data for a new update each value
or make send a command to another side to send me all value for the latest image of the system
it is hard for me to continue the build my project any deploy fetch-all data from another side
Hi, to me it seems normal that the SVG is in the initial state again after a deploy. And that you need to get the current status of the switches (after a deploy) and send those to the SVG node to visualize them. And of course - as long as we haven't implemented a server side DOM tree (see my sketch above) - unfortunately you also would need to update your context. Although that is how I see it, but I might be mistaken...
I am afraid that lost data received while I am in the deploy process
So I will make an Interrogation general to restore all current value of the system after deploy finished
