I’m considering changing EWF’s “initial request data modifications” to happen before loadData rather than after. I am building a page in the System Manager that displays emails, and I want it to be able to check for (and download) new mail every time it is loaded, and include the new mail in the display. EWF does not currently allow me to do this.
@greg_smalter and @samrueby, do you have any objections to this change? The method will still only run once per request regardless of post-backs and transfers, so I doubt it would break anything that you’re doing.
Modifying data in loadData is a very bad idea because the cache is enabled there, and at some point we may decide to start throwing exceptions if you try to execute a modification in a cache region.
Oh, I misunderstood. You didn’t mention anything about modifying data, just loading new mail. I guess I missed the word “modifications” in the initial request thing too.
Would this help me for this situations where I add some database-saved search preferences (that used to be optional parameters) and for users visiting the page for the first time since that change, I want to insert a row in the UserPreferences table so that LoadData can assume it’s there?
Not exactly, unfortunately, because it will not run before the first loadData pass on post-back requests. So if the user’s first interaction with the system since the change is to post back a page, the row wouldn’t get added.
I don’t think I’ve ever used this but if I had I would be really confused that it’s named “initial request data modifications” and doesn’t run before loadData.
Thanks for drawing attention to the poor-quality name, @samrueby. I’ve renamed the virtual methods to executePageViewDataModifications. But by the way, this whole thread is about how they now run beforeloadData.