Feature/include file input #31
Conversation
dragos-ana
left a comment
dragos-ana
left a comment
There was a problem hiding this comment.
Thanks for the nice addition!
I left some comments / questions.
| with open(include_file_server, "rb") as fr: | ||
| with open(include_temp_path, "wb") as fw: | ||
| fw.write(fr.read()) |
There was a problem hiding this comment.
shutil.copyfile might be better for this. Also, what should this check provide? If a file with the same name is present in the initial file directory, then it should be copied to the temp dir? What about the case where you upload a completely new file, and within its INCLUDES section it references to a file which coincidentally has the same name as one of the files present in the initial file directory? Then it would basically get replaced by the old file, right? If so, this should be changed.
IMO, this function requires some comments to better understand the information flow.
There was a problem hiding this comment.
I commented the file so it can be better understood.
The reason why I added this copy functionality is, that if the user is working on a specific yaml file and uses the webviewer frequently, they should not have to upload the exodus file every time they open the yaml file. Now he can copy the .exo file into the server directory and it will be automatically loaded every time the file gets opened.
The important thing is that include_file_server does only refer to the initial directory if the file was uploaded from the server. Which would not be the case in most situations.
Of course I can remove this feature, but I believe that it could be very nice for quality of life.
I think it would be best if we had a small meeting about this and some other final things about the viewer.
There was a problem hiding this comment.
Yes, let's have a dedicated meeting for this. But good thinking!
| print( | ||
| "Warning: File does not have a .yml / .yaml / .dat / .DAT ending or is empty. Try opening another file." | ||
| ) | ||
| return |
There was a problem hiding this comment.
Why not raise an Exception?
There was a problem hiding this comment.
The viewer should not be closed if the user opens a wrong file. He can just open the right one without any problem. I can remove the Warning if you think its not adequate.
There was a problem hiding this comment.
You are right. But please use loguru, which I added in #32.
|
|
||
| self._server_vars["fourc_yaml_name"] = temp_fourc_yaml_file.name | ||
|
|
||
| self.request_included_files() |
There was a problem hiding this comment.
Here you removed the render_count part, which emptied the vtu path if a new file was considered. This was only done for "non-initial" renderings, because this function is also called at startup. The vtu path was then created subsequent to conversion after pressing CONVERT. Does this work reliably after removing this aspect? Does changing files make the visualization disappear until you press CONVERT?
There was a problem hiding this comment.
This is also a topic I would like to discuss. I removed the convert functionality (although some artifacts of it remain currently) as I did not see the need to explicitly ask the user to confirm. The vtu path is now set in init_pyvista_render_objects, so exactly as the actors are set up. This works reliably and I have not encountered any problems until now.
There was a problem hiding this comment.
Yes, we need to discuss this separately as well. I can understand the reasoning behind removing it, but I am not sure whether this should not be done in a clean, separate PR, rather than leaving artifacts, as you said.
|
|
||
| # contains the dict of the structure geometry section of the current yaml file. | ||
| structure_geometry_section = self._server_vars[ | ||
| "fourc_yaml_content" | ||
| ].sections.get("STRUCTURE GEOMETRY", {}) | ||
| # contains the name of the geometry file defined in the STRUCTURE GEOMETRY section. | ||
| geometry_file_name = structure_geometry_section.get("FILE", None) | ||
|
|
There was a problem hiding this comment.
This was a previous bug from my side, which was however fixed in #32 . We have to consider all possible GEOMETRY sections when looking for files, not only the structure geometry ones. This should also be included here.
2 participants
No description provided.