I am currently working on an image selection page where I have available images associated to a main object and a 'selected' 1 - 1 association that holds the selected image. When I press cancel on this page I want to delete all available images including the selected image, BUT only if the selected image is a new object. *Images are a specialization of the system.Image entity* Available images are created in the navigation flow to this page and never committed (usages in actions for commit returns nothing, the subflow I use to commit objects has 0 usages so far). The main object also is not committed anywhere on this page. To make sure a previsouly selected image is not deleted, I perform an IsNew() check for the selected image, which I retrieve over association. Because this objects has not yet been committed, I expect the function to return true. To my surprise the function returns false. To double check I created a subflow which tries to retrieve this uncommitted selected image from the database and against all odds (in my head) an object is found. (I XPath by matching mendix' innate Object id). My conclusion here then is that uncommitted objects are somehow still retrievable from database, which seems very odd to me. Does anyone know if system.FileDocument and/or system.Image perform some wonky background commit? Maybe the image uploader does it? Overall this is messing up clean UX in my application as now the user has to close the image selector popup AND close or refresh the previous page to see that their image selection was cancelled. Due to the structure of the pages and the logic they contain I will not be adjusting anything on that page. Am I being delusional, does IsNew() only work within the microflow the object was created? If yes, how are people supposed to have subflows to create objects and still have this check work? (<-- we subflow creates for security and reusability) Any answers and knowledge welcome, that was my TED talk thanks for listening
asked
Lan Gnezda
2 answers
2
It's the image uploader. The file uploader does the same thing. It immediately commits the filedoc / image specialization. You'll have to use other logic to delete or not, like existing associations (not being your current mainObject) or a boolean that you set true once it has been properly selected and saved, so you can delete as long as it's false.
answered
Martin Koelewijn
1
This has come up before. FileDocument and Images are committed by the file manager widget. Thorsten recommends adding a cancel microflow to delete the object and the actual file from storage.