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
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev