On Dec 30, 2008, at 12:07 PM, Darin Adler wrote:
I have a few thoughts on this. The general approach seems OK.
On Dec 30, 2008, at 11:11 AM, David Levin wrote:
class ScriptResourceLoader {
I'm not sure "Script" is the right word here, but I don't have a better one. Up until now Script has meant "interface to the JavaScript interpreter" rather than objects outside that that are intended for use by script. But prefixes like "Programmatic" are uglier, so maybe we should stick with Script. Lets see if we can think of a better prefix.
ScriptResourceLoader sounds like the name for a ResourceLoader that loads Scripts. However, this is neither a ResourceLoader (in the subclass sense), nor does it load scripts. It is just a helper class to do the loading for XMLHttpRequest. Thus I would suggest the name XHRLoader or XMLHttpRequestLoader.
How were you planning on handling synchronous loads? Maybe the function for that should be here too as a static member function?
public: static PassRefPtr<ScriptResourceLoader> create(ScriptExecutionContext*, ScriptResourceLoaderClient*, const ResourceRequest&, bool skipCanLoadCheck, bool sendResourceLoadCallbacks, bool shouldContentSniff);
Despite their use in existing code I think booleans are a lousy way to handle options like these.
I think we can omit skipCanLoadCheck, since it's always false for XMLHttpRequest. For the other two I would prefer something easier to read at the call site, either named enums or a flags word. The best example I could find of the named enum approach is EChildrenOnly in markup.h, although the use of an "E" prefix isn't desirable. I couldn't find a good example of a flags word.
But this may be in appropriate, since we already use booleans for this purpose and you're just refactoring.
I believe XHR also never does content sniffing, so sendResourceLoadCallbacks would be the only flag that could have an effect. Does it actually differ for different XHR invocations? Regards, Maciej