We're trying to upload a picture using the File Upload component and store it on a parameter in the view for later use to store to a database. The problem we're running into is that it appears that the Perspective parameter might be a string that refers to the object, and not the object itself. How do I use a string to retrieve the object itself?
Tech tip: you're trying to store it on a custom property in the view - not a parameter. You might want to edit the original post to clarify.
If you really do want to store a file to a property value, you’ll need to string encode it somehow.
Unfortunately you can't store files in custom properties.
This thread may be useful to you
Why not just go straight to the database?
2 Likes
My Integration Toolkit has expression and scripting functions specifically to solve this problem, retaining original object identity in dictionaries attached to session, page, or view scopes.
These functions exist in my free module because Ignition's script wrappers for Perspective make it impossible (as far as I can tell) to construct weak references to sessions, pages, or views. In jython. Nearly trivial to do in a true java module.
With my module, you do not need to encode these objects at all--these features are compatible with unserializable objects.
(For the OP's case, the pageVarMap() is likely the best choice--workflows can change views without losing the stored objects.)
2 Likes
We have a form where the user is putting in new part information, and they have the option to upload a picture while they are entering the information. We can't write it to the database at the point that they upload the picture because the part doesn't exist in the database yet, so there is nothing to tie to the picture.
We were able to get it working with system.util.getGlobals() from the thread you referenced. Thank you!!
I hope you use more than a view shutdown event to ensure things get cleaned up. Storing file contents in .getGlobals() is a potential memory leak waiting to bite you. And if done as naive as shown in that thread, a disaster across multiple users. At the very least, there should be a layers of dictionaries for session ID and page ID, with a gateway timer that deletes keys that are no longer in a session list.
I hope you use more than a view shutdown event to ensure things get cleaned up. Storing file contents in
.getGlobals()is a potential memory leak waiting to bite you. And if done as naive as shown in that thread, a disaster across multiple users. At the very least, there should be a layers of dictionaries for session ID and page ID, with a gateway timer that deletes keys that are no longer in a session list.
Oops... that was a major oversite on my part. I haven't even been using a view shutdown event to clear these out... I've been clearing them on the form submittal. I'm glad I saw this. I feel really dumb. Thanks @pturmel
1 Like
It's really easy to forget things like this. Better to have a data structure that cleans up after users automatically.
We think we should be able to avoid a memory leak in our situation. We are removing the key every time that the view is closed. Also, in our particular case, we are sharing a key so that, at worst, we'll just overwrite a key that wasn't deleted rather than creating more and more keys that do not get deleted.
But I appreciate you mentioning this; we'll definitely keep an eye on it.
So, no possible way to have two users on this form?
It's a limitation we're willing to deal with right now. 
The team uploads pictures a handful of times each year, so we don't expect it to be a big issue. We'll go with something similar to what you suggested if we run into issues.