Using RegisterClientScriptBlock I reduce server requests.
But with RegisterClientScriptInclude I can separate HTML and javascript.
Which method should I prefer?
EDIT: Additional question - where do you store your js blocks. I get used to place them into resources files.
The RegisterClientScriptBlock method is handy if you want to modify the script somehow.
If you can have the script as a static file to include I would recommend that, as the browser would cache the file so that it would only be requested the first time that it's used. Given that the script is more than just a few lines, of course.
Use which method most serves your needs at the time. I don't think there's a rule that says you must choose one or the other for every single possibility.
Both functions should be used as last resort for JS. Best way to store and attach your JavaScript to the site is to use static linking.
Related
Ideally I'm looking for a Javascript resource loader that will:
(1) Allow me to make "ready" calls like head.js does, e.g.
head.ready(function() {
$("#my").jquery_plugin();
});
// load jQuery whenever you wish bottom of the page
head.js("/path/to/jquery.js");
(2) Load CSS files like yepnope (which can also handle file names with hash on the end by using the css! prefix). I don't particularly need the conditional load functionality (at this stage).
(3) Ideally, only load resources once even if multiple calls are made (head.js does this automatically, yepnope does this with a filter).
At the moment I'm resorting to using both head.js and yepnope, as I haven't been able to find one that supports both the first two requirements. Obviously this is not ideal, as both together (with filters and prefixes) come to 7kb minified. I think this is a bit too heavy as a bootstrap script.
One option is roll my own using a combination of the two and strip out the functionality I don't need... but I'd rather stick to one that's going to be supported to reduce the pain of future updates etc.
So we stuck with a combination head.js and yepnope until something better comes out.
When the path refers to the actual folder structure and points to the page it's not a problem, i.e. "/Default.aspx/MyMethod", however if "/" brings up "Default.aspx", then "/MyMethod" means something different. Is it even possible at all?
A possible solution, and probably a better one, is to use a web service, which is what I'm using at the moment.
You can add the following:
PageMethods.set_path('/yourpage.aspx');
I found this solution here
I've been looking on the Internet for a fairly clear explanation of the different methods of registering javascript in an asp.net application. I think I have a basic understating of the difference between registerStartupScript and registerClientScriptBlock (the main difference being where in the form the script is inserted).
I'm not sure I understand what the RegisterClientScriptInclude method does or when it is used. From what I can gather, it is used to register an external .js file. Does this then make any and all javascript functions in that file available to the aspx page it was registered on? For example, if it was registered in the onLoad event of a master page, would all pages using that master page be able to use the javascript functions in the .js file? What problems would arise when trying to use document.getElementById in this case, if any?
Also, when it is necessary/advantageous to use multiple .js files and register them separately?
I appreciate any help you can give. If you know of any really good resources I can use to get a thorough understanding of this concept, I'd appreciate it!
Here's an article on referencing JavaScript from master and content pages:
http://www.dotnetcurry.com/ShowArticle.aspx?ID=273
I am using ASP.NET MVC project and jQuery to handle async requests. Sometimes for an async request I need an initialization JavaScript snippet to be returned and executed together with an HTML snippet (I want this JavaScript to be rendered on server).
For now I am using my own ScriptsHelper class with a RegisterStartupScript() method (adds data to HttpContext.Current.Items). Then in global.asax HttpApplication.EndRequest() for async requests I append all registered scripts to the output (enclosed in tags). jQuery.fn.load() successfully executes them when the received HTML is appended to the DOM - this is exactly what I need. Do you think it is "correct" (good) solution, or maybe you can suggest something better? Thanks.
I encountered a similar situation in a project before I started using jquery and wound up resorting to using eval(). I was returning a javascript text snippet as part of the value of a non-visible DOM element along with the rest of the HTML I was inserting into the DOM.
I had a lot of trouble debugging this type of dynamically generated javascript in IE6 so this solution worked out decently for me because I could inspect the value of the DOM element that was getting eval'd. However, I've always been leery of using eval.
It sounds like your solution has a reasonable architecture for the server-side rendering as opposed to my spaghetti-code and this technique looks like it fits right in with the spirit of jQuery.fn.load so I wouldn't worry too much.
Yeah I think that jQuery is calling eval() internally for you - are you using append? I think that this technique works pretty good most of the time. If the data returned from the server is in a list that is repeated you may want to look at using the live function added to jQuery 1.3 It allows you to attach an event to all current and future elements matching your selector. Checkout these articles:
Live
jQuery Live Events
Also as something else to consider is a tool to help manage scripts and css for asp.net mvc. I have been using this and I love it as it combines files as well as compresses them. You can configure it all from you web config too.
The ASP.NET ScriptManager control automatically inserts all kinds of inline javascript like PageRequest initialize. Is it possible to remove or move this to an external js file?
Also, the scriptmanager always adds __DoPostback even when not used on the page, how can this be avoided or also moved to an external file?
First of all the "__DoPostBack" is inserted by controls that can cause a postback such as the DropDownList with the AutoPostBack property set to true. Since the ScriptManager basically intercepts the traditional postbacks, I believe that's the reason for it to insert the function.
-- The following is just me thinking... :)
Now, about moving everything to an external file. It's not easy, but it "could" be possible.
The problem is that ASP.NET is generating the scripts at runtime, so you cannot do anything about it statically. What you need to consider is why you would want to do this in the first place.
The fact is that much of the generated script is dynamic, which makes it rather hard to cache.
But, if you really need to, you should have a look at both HttpHandlers and HttpModules.
Basically you need to somehow extract every script tag (without the src-attribute set). This could be done in a HttpModule on the BeginRequest event of the HttpContext. Now you need to extract all the necessary pieces of information and replace it with a reference to a specific HttpHandler that can service as the replacement.
But to make any difference at all, it is necessary for you to do some sort of caching of the existing script. You could probably use the ASP.NET Cache for that.
The tricky part would be to compare an existing cache entry with the new and determine whether or not to get the cached version (pointing the HttpHandler to an existing entry) or to generate a new entry. If you have a lot of scripts, it's most likely to be a rather expensive operation.
Furthermore you need to determine whether the client can cache on it's own (e-tags etc. could come in handy). What's important is for the client to avoid downloading the same unnecessary scripts each time (I believe that's your ultimate goal?).
So to recap:
Build a HttpModule to take care of the page rewriting and putting the extracted script into some sort of cache (eg. ASP.NET Cache).
Build a HttpHandler to point to for the extracted script (it should stream the contents from the cache). The handler should be put in place of the extracted inline scripts.
Create some sort of algorithm for determining cache invalidity. I don't know from the top of my head what kind of script that could change between requests.
Btw. script externalization is tricky at most, so you need to be careful not to introduce bugs that are impossible to fix ;)
Not an extact solution, but I have tried doing this myself before without any luck... mostly because of too litle time. When you are payed to do a task, this kind of optimization can't be justified... :(