Revision r3010 breaks javascripts in Normal/Performance mode

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Update to prado trunk >= 3010
2. grab an application using ajax controls and switch it to Normal/Performance  
mode
3. Play with some ajax controls on it

What is the expected output? What do you see instead?
I expect ajax controls to work normally. Instead they return a 
"Prado.ScriptManager is undefined" error.

Please use labels and text to provide additional information.

The "prado-lazyload-in-callbacks-patch" assumes that prado loads each 
javascript file in a single <script src=""> entry in the base page. This list 
is then compared to a list of "needed js files" that is returned inside the 
X-PRADO-SCRIPTLIST section.
When in found that when in Normal/Performance mode, the first assumption is 
wrong. In fact, in this case Prado adds one single <script 
src="clientscripts.php?js=ajax,validator"> entry pointing to a php script that 
generates on the fly a single-file jsmin-ed version of the needed js.

Original issue reported on code.google.com by ctrlal...@gmail.com on 6 Sep 2011 at 5:42

[GoogleCodeExporter]

I probably missed to explain the real cause of the "Prado.ScriptManager is 
undefined" error in the ticket description. When the Prado clientside receives 
a list of the needed scripts inside X-PRADO-SCRIPTLIST on callback, this list 
will surely contain "prado.js".
If the previous list (postback) has been served with "clientscripts.php", prado 
clientside won't find "prado.js" inside the "already loaded javascripts"  and 
will try to load the prado.js again. This means that the "Prado" js object will 
be redefined in the middle of the callback, causing the problem.

r3036 introduces a workaround for the issue, forcing the non-debug 
"clientscripts.php" way to deploy javascript files on callbacks, too.
This is not exactly a fix, but at least workarounds the problem by now.

Original comment by ctrlal...@gmail.com on 6 Sep 2011 at 5:51

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I was not aware of this issue, but in the long term it should be resolved by 
actually dropping clientscripts.php and introducing per-file script compression 
in the framework.

The current implementation based on clientscripts.php is actually very 
ineffective (unless you're using only a few page types on your sites), because 
whenever there's a different set of scripts need in a page, it has to 
compresses the new set of scripts invidually and transmits all of them to the 
client side. Considering only 5 independent base scripts there are ~600 
possible combination of them.

That means, that if you're using a slightly different set of controls on your 
pages requiring slightly different base scripts, every page will actually have 
to quasi re-request and download a slightly different compressed set of 
scripts, which however, will also include (or constist mostly of) scripts 
shared with and already downloaded from previous pages. This will results in 
defeating the purpose of compressing the scripts in the first place, as it will 
results in far-far more bytes transferred to the client side then actually 
needed. 

If, however, scripts would be compressed on a per-file basis, browser caching 
would ensure that only the script files not yet loaded will be downloaded when 
requested, and there would be no redundant compression and transmission of 
script content. It would also solve this issue with the client-side actually 
being unable to determine the correct set of scripts loaded.

Original comment by google...@pcforum.hu on 18 Sep 2011 at 9:16

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Btw. the correct fix for the original issue would be to modify 
clientscripts.php so it appends some extra lines to the script file served up, 
which would register and mark the individual script files included as part of 
the single compressed script file as loaded in the lazyload client-side 
registry. This would prevent the latter from re-downloading and re-intializing 
scripts already loaded as part of some request to the clientscripts.php.

The appended lines should look like this:

if (typeof(Prado.ScriptManager)!="undefined") 
{
  var includedScripts = < array of canonical urls of individual scripts included in the compressed script file >
  for (var i = 0; i < includedScripts.length; i++)
    Prado.ScriptManager.markAssetAsLoaded(includedScripts[i]);
}

I haven't tested the above code and have included it here just as a hint how to 
accomplish the task.

Original comment by google...@pcforum.hu on 18 Sep 2011 at 9:34

[GoogleCodeExporter]

I know mine was just a workaround, and i agree that the current use of 
clientscrips.php tipically creates more overhead than what it tries to solve.
Actually clientscripts.php it's even a simple method to dos (as in denial of 
service) a webservice running prado: just call it with different 
combinations(and order) of scripts.
Publishing the single js files, maybe a jsmin-ed version in assets/, and let 
the client browser cache do its job is probably the simplest - and more 
performant - method.
I'll start working on it, unless somebody has a better idea.

Original comment by ctrlal...@gmail.com on 19 Sep 2011 at 11:37

[GoogleCodeExporter]

I committed a test patch as r3039. It basically removes clientscripts.php and 
adds a "min/" subdirectory in the assets/xxx/ folder where prado publishes 
javascripts files.
An .htaccess has been added to enforce proper clientside caching.
It almost works here, i'm open for comments.

Original comment by ctrlal...@gmail.com on 20 Sep 2011 at 9:38

[GoogleCodeExporter]

Added a small fix in r3040, since i inadvertently reintroduced the bug

Original comment by ctrlal...@gmail.com on 20 Sep 2011 at 2:45

[GoogleCodeExporter]

The changeset seems to work fine here, thus closing the ticket.

Original comment by ctrlal...@gmail.com on 22 Sep 2011 at 1:31

• Changed state: Fixed