I’d like to create a pdf view that doesn’t update every time I change a parameter.
Of course I could set the duration_guess to create a slow view. But then the update button appears every time a parameter is changed, telling the users that the view is no longer up to date. Which is not ideal.
The solution I’m thinking of is to set the specific params on which the update button should appear, or using hashlib or memoize to set some dependence on this view. However, I’m not sure on how to implement this in the PDFView.
@Tom_Nillesen welcome to the club. See these threads
The current solution uses a text field so to avoid having the app running every time you type a letter we use a high number on the duration_guess.
I was thinking what about having a silent field? In this case, the silent field will be the text, and having a button we will search from the location provided.
It could be useful having a silent field to pass data that shouldn’t trigger the application until is requested.
What do you think
Is there a method to trigger a View without having to press update? For example, I have a list of images in a dropdown menu and want the PNGView to update to the image selected when I change that option. I know setting the duration guess to a lower number will have it update, but this triggers an update with every change in the parameters and having it load everytime is annoying.
Here is a video example of what I’m doing. Pressing update for an image to show up everytime is not ideal.
I don’t know if a single editor will solve this UI issue.
Perhaps good to elaborate first.
As I understand, you are now using the app to generate reports. The user uploads images and in the same session generates the report. After generating the report, the user has no need to access the images anymore. Is this correct?
If your problem is the manual act of adding and deleting an entity, this can be solved by deleting the entity through the api as described above. If you are worried about storage of deleted files, there is curren…
Its good to see that I’m not the only one having this issue and that they are working on it as feature request.
I’ve flagged this thread as a feature request.
I’m wondering what about the current implementation makes it not ideal for your usecase:
is the appearance of the update button giving the user the (false) impression of an error?
is the action of pressing the button evey time cumbersome for the user?
is the time it takes to recalculate the pdf view the problem?
You could indeed implement
memoize on a function within the PDFView. This will not solve the popping up of the update button, but it should quickly refresh the view after pressing update.
Hope that helps!
all three points you name are the case, a red button that tells the user that the view no longer matches the params is a trigger that shouldn’t be used when the params are of no influence on the view.
thanks for the flag