New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
unformatted {pic} string in node_details.json #828
Comments
Seems related to this comment in OZfunc.py: # TODO - there is a bug here where we don't actually substitute {pic} into the name
pic_ncols = ["{pic}1","{pic}2","{pic}3","{pic}4","{pic}5","{pic}6","{pic}7","{pic}8"] I see the same on https://www.onezoom.org/. So maybe not a new issue? Does it result in something breaking? |
Yep, I think that's the one. I forgot I had commented about that! It doesn't break anything, no. But I guess this is a good time to fix it. This call happens a lot, so extra bytes will add up. |
If you're fixing it, don't forget the other end: OZtree/OZprivate/rawJS/OZTreeModule/src/factory/data_repo.js Lines 291 to 298 in fb96f14
|
Perfect, thanks for the hint @lentinj |
I'm inclined to make this "p1", "p2", etc, to cut down on bytes transferred, or "im1", "im2", etc which is maybe more obvious from the outside? |
So you mean regardless of whether we're using rep, rtr or rpd, the column names returned to the client would be the same? i.e. not match the underlying DB cols that we're using? |
I'd prefer "pic1", for naming consistencies' sake. Lots of internal functions / variables in JS-land use "pic" as a prefix. |
Good point. The JS doesn't seem to know at the moment about the |
I'm inclined to do as we obviously intended and change these to |
The risk is that doing this will turn this into a more complex change. e.g. in the data_repo.js code that @lentinj points to, it hard codes the column name, and would need to know what name to use based on context? I don't have enough understanding on how we make use of the picture column names on the client side. |
Yep, it's definitely more complicated, but I think worth looking at. It seems wrong that the JS has no idea of the type of image, and I think if could be the source of some subtle bugs to do with which is displayed. This is almost certainly something to discuss with @jrosindell. It doesn't need to be fixed for v4.0 |
in addition to data_repo.js above, we'd likely need to change: API.py: col_headers.js: Anyway, since this is not new, and not blatantly broken, it can probably wait as you suggest. |
I'm seeing json return values like:
I'm pretty sure that the "{pic}1" type keys are errors in string substitution, where we have forgotten the
f
in front of the string.The text was updated successfully, but these errors were encountered: