G. Andrew Duthie wrote:
So, I tried a simple repro, using a web block containing a preparation that uses a forge component to artificially pause execution for 5 seconds.
I put 4 If blocks on a screen, tied to 4 boolean local variables, all of which default to a value of False, and put an instance of the web block in the True placeholder of each If.
With all local variables set to the default value of False, the page rendered instantly.
With a single variable assigned the value of True in the screen preparation, the page rendered after approximately a 5 second delay. Each additional True value for the variables underlying the If blocks resulted in an additional 5 second delay in rendering.
So for my test, when the web block is inside an If that evaluates in a way that does not render the web block, it has zero impact on screen rendering and load time.
Again, it would be helpful if you could share a simple repro, as an OML, as there may be something you're doing that is resulting in the web blocks always executing, even if they're not visible on-screen.
You are correct that the prep logic does not run for these blocks within the blocks. That is not what appears to be the issue.
The ASP/ASCX files of our primary web application consists of approximately 37MB. To better serve our customers we allow them to choose from 5 different templates, with about a dozen different blocks. (Which themselves contain dozens of other blocks)
In order to allow a database driven model for the users to choose and manipulate these blocks, we must have all of the available blocks inside 1 'master' block, and the database values determine which block is loaded in which location of the template. This allows nearly all of our functionality to be accessed via the dashboard.
Unfortunately, from looking at the straight ASP/ASCX code, ALL code for ALL blocks on each page and block is generated on the page load. It's not running any logic, but it is compiling all of the code for that logic into the central page when the ASPX is loaded.
So instead of 1 page loading 8 blocks (with an avg of 5 subblocks each), we're loading 5 dashboard layouts, with 8 blocks each, and loading 12 blocks in each of those 8 blocks, with probably 5 blocks average in each of those 12.
At this point, instead of loading 40 blocks in an ideal situation (which is all you ACTUALLY see when the page loads) the code loads 2,400 blocks of code.
Math Follows:
Ideal:
5 avg blocks for
8 total dashboard blocks in a single template
=40 loaded in an ideal world
VS
What Happens:
5 avg blocks, per
12 'all available' total blocks per
8 total dashboard blocks loaded for each
5 possible dashboard layouts.
=2,400 loaded via the ASPX