I have a page with small "applications" in it, and I want to switch between them without reloading the page.
Is there way to remove all the js code and variables and functions and intervals etc. etc. from the page, for one application which presents itself as a .js file?
Or would it be easier to just refresh the page?
If you have each application in its own namespace, (see for example here: http://msdn.microsoft.com/en-us/magazine/gg578608.aspx or here: JavaScript Namespace Pattern ) you could pass those namespaces into your particular part of the page, which would probably achieve something like this.
However depending on what kind of performance you want putting the applications in an iframe and dynamically loading different pages there might be better.
Related
I have a very basic question about grouping (jQuery) plugin initializations-- and really any type of script-- into a single script throughout a website: in my templates, I typically have a "tools.js" file that includes various plugin initializations, click functions and the like. For the sake of ease, neatness and number of server requests, I like to keep these functions/script calls centralized in a single file, however, on certain pages, various scripts won't apply-- say, a fitvids.js script initialization that might be used on one page with a video, and not on another. Thus, I'm wondering if this is problematic in any way, i.e. can this create problems if a certain library isn't included on a given page-- but it's initialization is-- or a selector referenced in a click function is not present on a given page?
Thanks for any insight here.
In my design, I will have only shared code like plugin definitions or common utility methods shared between pages. The functional code like event handlers or plugin initialization for each page will be kept separate.
If there is a cross cutting concern in multiple pages then it will be either converted as a plugin or as a utility method which will be placed in a shared file but the actual usage will be done for each page separately.
If the selector is not present in the DOM and has a click handler in js, it should not be a problem. The reason behind is that the click function is never triggered. It is an issue if the attached handler is executed by any chance and js can't find your selector.
I have many view templates where i have inline javascript specific to that view.
for eg:
app/views/something/index.html.haml
.some-id
%h4 Something
#this javascript is not reused anywhere. Used only in this view
:javascript
$(document).ready(function() {
$('.some-id').addClass('something')
})
Is it a good practice to have the views like above?
It is definitely a pain to maintain inline javascript across multiple views. So i started moving them slowly into one single javascript file. But i am not sure if that's a good thing because, all the javascript will now get executed for all the pages.
So which is the best place to put view specific javascript?
If you are worried about page load time, you should use something like loadjs. It is just not maintainable to be place JS in your views like that. For super simple projects then maybe, but in general you should stay away from it.
Another thing to note is that browsers will cache your javascript when it is loaded from a file. They cannot do this when it is inline because the HTML is rendered every page load. So you probably are looking at an overall performance loss when doing it inline, even without loadjs.
I have a website that has a fixed menu, header, etc. and loads the main content area via AJAX based on the menu clicks.
These "pages" rely on a lot of Javascript and CSS which are individual for each page. Since a user can potentially visit many pages, I want to unload the page-specific JS and CSS. The CSS was straight-forward, but removing the <script> tags does not remove the loaded Javascript (I can still call functions defined in it).
How can I really "remove" the JS? I don't want the memory overhead, or to have to worry about name clashes between pages.
You can load your functions into a page specific object. This will require you to make all your page specific calls though that object. When you want to unload the page, make that object point to something else (say null). Now you don't have references to the object, and it will be cleaned up by the runtime. (Assume nobody else points to it. This is trivial to enforce.)
My understanding (from this post on Perfection Kills) is that you can only completely remove javascript function declarations if they were created using eval(). If that is the case, you can remove the function by calling
delete funcName;
If the function was not created using eval(), the best you can do is redefine it. There are numerous examples of that. Here's one: javascript function redefinition
So, I've written a little javascript widget. All a user has to do is paste a script tag into the page, and right below it I insert a div with all of the content the user has requested.
Many sites do similar things, such as Twitter, Delicious and even StackOverflow.
What I'm curious about is how to test this widget to make sure that it will work properly on everyone's webpage. I'm not using an iframe, so I really want to make sure that this code will work when inserted most places. I know it looks the same in all browsers.
Suggestions? Or should I just build one hundred web pages and insert my script tag and see if it works? I would hope there is an easier way than that.
Once you have confirmed that your javascript works cross-browser in a controlled environment, here are some things that might cause problems when used on an actual website:
CSS
You're using a CSS class that is already being used (for a different purpose) by the target website
You're using positioning that might interfere with the site's CSS
The elements you are using are being styled by the website's CSS (you might want to use some sort of "reset" CSS that applies only to your widget)
HTML
You're creating elements with the same id attribute as an element that already exists on the website
You're specifying a name attribute that is already being used (while name can be used for multiple elements, you may not be expecting that)
Javascript
What is the expected behaviour without Javascript enabled? If your script creates everything, is it acceptable for nothing to be present without JS?
At very basic you should make sure your widget works for following test-cases. I am sure then it will work on all web-pages -
http/https: There should not be any warning for HTTPS pages for unencrypted content.
<script> / <no-script>: What if JavaScript is disabled? Is your widget still visible?
What happens when third-party cookies are disabled? Does your widget still work?
Layout-box restrictions: When parent div element's size is less than your widget. Does your widget overflow the given size and destroys owners page?
By keeping all your Javascripts under a namespace (global object) with a very unique name, you should be pretty much OK. Also, you can simply use an anonymous function if you just want to print out something.
Similar question: How to avoid name clashes in JavaScript widgets
I have been tasked with improving the current mess that is our JavaScript "strategy"; we're an online shopping company and my boss has given me time to do this properly. He is very keen on keepin this modular and increase the reusability of the components.
Our HTML is being rendered with JSP and we have lots of custom tags writing out, for example, information about products without the web designers needing to worry about it.
Now, we want to do similar things with JavaScript. The web designers should be given a set of custom tags, like, say,
<foo:draggable>
... some HTML here ...
</foo:draggable>
that will wrap the HTML in a <div> with a drag bar at the top and a close button.
My idea is to mark the div with a unique namespaced CSS class name, like foo_draggable, and then put all my functions in a single JS file. That JS file then sees if there are elements with the CSS class foo_draggable in the DOM and if it finds any it will attach the required event handlers.
However, I am worried about scaling problems, and wondering whether it is a good idea to have lots of selector queries running when they quite often aren't going to be used.
The first alternative would be to initiate each draggable item explicitly but that would mean putting <script> tags all over the place. The second approach would be to not put all UI function in one file but rather just download the ones I need, but that would mean lots more HTTP requests and slower page load speed.
Has anyone got experience with this?
What about having two classnames?
<div class='foo fooDragable'></div>
<div class='foo fooSortable'></div>
You add the class 'foo' to all your elements that require javascript modification.
Your javascript has to check the dom only once for foo.
var $foo = $('.foo');
Afterwards you can search within this array which should be way smaller than the complete dom.
var $dragAble = $foo.filter('.fooDragable');
Have you considered or taken a look to JSF? I know it's a major change if you aren't using JSF yet. But there are lot of ready-to-use JSF component libaries with an ajaxical sauce, for example RichFaces, IceFaces, PrimeFaces, etc. It's almost a waste of time to create components/tags for it yourself.
Alternatively you can replace all Javascripts to use the great jQuery JS framework.
Depending on how many separate components you have, the extra overhead of running the selectors might not be a big deal. You can initialize all the components just the once, when the page is loaded. Anything that's not present on the page simply won't get initialized, and will incur no further overhead. In most JavaScript frameworks, selecting by classname (or tag name) is pretty fast. It's only the complex selectors, which aren't natively supported by the browser, that are slow.
If you have a few commonly used components, and then a set of less commonly used ones, it may be worth splitting those up. Keep the commonly used components in a single JavaScript file (minified, served with compression and aggressive caching), and load that in every page, regardless of whether it's needed or not. Caching will ensure it's only downloaded once, and it'll only be one small HTTP request. For the less common components, keep them in separate files (ideally, one per component), and add a script tag on pages that use them.
I'm not entirely familiar with how JSP works, but it might be possible to do this automatically - if a tag is included in the document, add a script tag for foo_widget.js in the document header, or something like that.