In my Rails application, when a user saves, it uses Ajax to save the post and then execute the update.js.erb file. In that file, I have some jQuery:
$('body').append('<div class="message">Saved</div>');
Because I have it this way, every time the user saves, it adds more <div class="message">Saved</div> in the body. Is there a way I can stop that or does it not matter?
A lazy (but easy) method would be to clear the other messages before showing your new one:
$('.message').remove();
$('body').append('<div class="message">Saved</div>');
First off, unless the save is happening thousands of times, it probably doesn't matter. Remeber that images are very large so a few kb of extra text in a web page pales in comparison to a few images.
Second, you have several options to only ever have one of these in the DOM:
After showing it to the user, then remove it from the DOM (perhaps on a timer).
Have one and only one message and show/hide it when needed (this is probably simplest).
Look to see if one is already in the page and reuse it.
For example, to find a previous message object (that starts out hidden) and show it for a brief period of time, you could use this:
$(".message").html("Saved").show().delay(2000).fadeOut(1000);
If you used that, you would just put the message object in your page once to start with, either in the original page HTML or just append it once in your page startup code. Then, have CSS that defaults it to hidden so it only shows when you want it to.
Or, if you're using a CSS3 transition based on a class name, you can do just use jQuery's addClass() and removeClass().
Related
Is there a way to group div IDs that are scared across multiple pages but get to be called to the same page at some point with Jquery.
I want to hide or show all the divs in a group while showing only a certain group. The reason some group gets to be included in other functions and writing all the list of this many div IDs is somehow not wise.
2nd question.
How do I program a button to reload page and then after run a function with jquery?
ok let me add some code to make sense of this reload problem.
$('#accountresult').click();
location.reload(); //Should reload page 1st and then function
$('#button').show("slow");
$("#Atresult").load("source_cxchange.html #account");
$("#result, #homeresult, #appleresult" ).empty()
});
but rather, it only runs reload and dies, someone please correct the syntax of putting two functions to successively follow one another.
My advice would be to group them using a class rather than a collection of ids. That way you can target them all at once with:
$('.someClass').hide()
As for reloading the page and running a function afterwards that gets a bit trickier can you explain what you are trying to achieve?
When you refresh the page you lose the javascript callstack so you will have to set a querystring or use cookies/local storage to persist a value. You can then use jQuery's onLoad() function to run your function only if the url parameter or cookie exists.
1) Assign some class to those ids and use $('.someclass') to refer them.
2) To reload page, you will need to call 'location.reload();'. then you can do whatever you should in $(function() {});, which is called whenever page is loaded.
Anytime I click on a link/button anywhere on my site that performs/calls a GET or POST (Ajax and non-Ajax), if it takes more then a few seconds I would like to display a loading gif. I know how to do this on an individual basis, but I would like to know if it is possible to create a function that will do this automatically and then hide the gif when finished (assuming it does not redirect to a new page).
I found this but this does not work with the post method for spring security for example.
It may be a case where it is not possible or requires more effort than it's worth. I would just like to know if it is possible and if so how might it be approached.
The only constraint is that any methods calling the post or get should not need to be aware of this so called "listener".
This is tagged jQuery so I'm giving a jQuery answer for simplicity. This is also solvable in a relatively simple manner without it.
Hooking on every request:
Let's say your method is called myMethod.
GET/POST requests may be triggered the following ways:
Form submits, in which case you can select the form $("#formID").submit(myMethod); . Note that if myMethod returns false it will cause your form to not submit
AJAX in which case you can use $.ajaxStart with $.ajaxStart(myMethod)
"a" tag clicks, and other click handlers, in which case you can perform $("a[href]").click(myMethod) , note that this selects all a tags with an href attribute, you might want to change the selector to suit your needs
Image loads which you can handle like explained in this question.
Script loads which you can detect like explained in this question.
Stylesheet/Link loads, which is explained in this blog post. You can add a hidden element to the CSS and check if the style was applied in an interval, and when it does call myMethod
What you can't do:
If your page has a plugin like Flash, or in general anything your JavaScript does not have access to, you can't hook on requests it makes.
The case of displaying a 'loading' gif.
From what you're asking it seems like you only care about image requests, and AJAX requests (correct me if I'm wrong), since external pages that take a long time to load NOT in an AJAX requests can (should) implement that .gif logic on the new page. This could be handled as I explained above.
Although you can hook every case, I would not do so. I would create a method that loads the 'loading' gif into a place and accepts a url. If that url is an image (for example, by file extension if that's ok with your mapping) use the logic in the image load detect linked question, if it's AJAX load the loading gif to where the data will be loaded, and replace it with the data on a .done() handler.
Here is a question about how to do this for an image, here is how to do it for AJAX . The two can be easily combined into a method which is what I believe you should use.
Almost all web pages that I see designed to set the focus to an input box add the code into a body onload event. This causes the code to execute once the entire html document has loaded. In theory, this seems like good practice.
However, in my experience, what this usually causes is double work on the user, as they have already entered data into two or three fields and are typing into another when their cursor is jumped back without their knowledge. I've seen a staggering number of users type the last 2/3 of their password into the beginning of a username field. As such, I've always placed the JS focus code immediately after the input to insure there is no delay.
My question is: Is there any technical reason not to place this focus code inline? Is there an advantage to calling it at the end of the page, or within an onload event? I'm curious why it has become common practice considering the obvious practical drawbacks.
A couple thoughts:
I would use a framework like jQuery and have this type of code run on $(document).ready(.... window.onload doesn't run until everything on the page is fully loaded, which explains the delay you have experienced. $(document).ready(... runs when jQuery determines the DOM has been loaded. You could probably write the same sort of logic without jQuery, but it varies by browser.
I prefer to keep my Javascript separate from my HTML because it allows for a cleaner separation of concerns. Then your behavior is then kept separate from your document structure which is separate from your presentation in your CSS. This also allows you to more easily re-use logic and maintain that code — possibly across projects.
Google and Yahoo both suggest placing scripts at the bottom of the html page for performance reasons.
The Yahoo article: http://developer.yahoo.com/performance/rules.html#js_bottom
You should definitely place the script in the appropriate place if it means the correct user experience -- in fact I would load that part of the script (Used for tabbing inputs) before the inputs to ensure it always works no matter how slow the connection.
The "document.ready" function allows you to ensure the elements you want to reference are in the dom and fires right when your whole document dom is loaded (This does not mean images are fully loaded).
If you want you could have the inputs start out as disabled and then reenable them on document ready. This would handle the rare case the script is not ready yet when the inputs are displayed.
Well if you call it before whole page has loaded you really don't know if the element already has been loaded when you make your call. And if you make your call in pre-hand you should check if the element really exists even if you know it always should.
Then to make the call inline, which might seem ideal. But on the other hand it's really bad if a page takes that long to load that you can make several inputs during the loading phase.
Also you could check if input has been made etc.
Also it is possible to check if any input on page contains focus if($("input::focus, textarea::focus").length)... and otherwise set focus on desired input.
Use the autofocus HTML attribute to specify which element should initially receive focus. This decouples JavaScript and gracefully degrades in older browsers.
I have a dialog box that has settings associated with it. When the user clicks the "settings" button, a form is displayed so they can modify them.
What is more efficient:
to have the settings div exist hidden on the page and display when needed
OR
to create the settings div and populate it with data when needed?
In the first scenario you don't need to create the DOM elements and populate them every time, but if there are many dialog boxes open at once (a common situation) then the amount of elements on the page is pretty large and many of them are not going to be used often. But in the second situation, elements are created and appended to the DOM which gets expensive.
I'd suggest you to "cache" your html on the page, but enforce browser to do not render it until necessary (until user request the data, or simply scroll to it). The main idea is to add your html (with data) to the page, but comment it out. For example,
<div id="cached-html">
<!--
<div>
...some custom html here
</div>
-->
</div>
Then once user requested the html, you can do the following:
var html = document.getElementById('cached-html'),
inner = html.innerHTML;
html.innerHTML = inner.substring(4, inner.length - 4);
Pros. is that you don't bother your browser with initial rendering (later you can simply user display:none to hide it again), so your page renders faster.
And another note - if your data (and as a consequence inner html) changes frequently, then it will be better to re-render it each time user request it, but if it is almost static, then hide/show should be more effective.
There can be problems either way, it depends on your page. If you already have a lot of elements on the page, it may be better load add them when you need them. If your page is already very "scripty" you may want to load the elements and show them when needed.
The real question is what would be better for your page, more script, or more dom elements.
When you have to display same setting div at multiple places.
Keeping that hidden is a better solution.
Remember that creating a new dom element or cloning a existing dom element gives almost same performance, but for code clarity/maintainence cloning or template is better.
Implementation using template: Make a template of div setting and keep that hidden:
<div class="template_setting">
Your settings(children of template_setting)
</div>
Javascript/Jquery code:
-Whenever someone opens a dialogue box, make a clone of childrens of template_setting and append to div_dialogue.
-As you may have multiple templates on the same page( which is not always true).
Apply a custom event on the id of newly created setting div.( keep id of each setting div different, you can increment each one by some character/number).
$('#dialogue_opener').click(function(event){
$('.template_setting').children().clone().appendTo(div_dialogue)
.trigger('adjustSettingID');
Consider a hybrid solution. Load the "settings" div after the page is ready. This way, the user won't feel the extra "expense", and you'll have the div ready for when you need it.
I've typically seen that rendering from JavaScript is pretty darn fast. I've built lots of "just in time" menus, grids, and forms and the users can't tell the difference. The nice thing about it is that you don't have to keep a form current, just blow it away and default everything to the data in you settings object. Makes for cleaner code in my opinion.
I'm not too familiar with javascript, is there a way to manipulate the DOM before the page is displayed to the user?
I'm using GWT which makes you create the page elements via javascript. This is kind of convenient, but it appears that all the javascript code is executed after the page is first shown to the user. This has the effect of showing the page as a blank white screen, then all the UI elements popping onto screen. The effect is really apparent when switching between pages.
If I were using php or jsp, it looks like the page ui elements are already prerendered and the browser won't show a blank white screen before display.
So is there any hook in javascript where we can manipulate the DOM before the browser clears out the contents of the last page shown?
-------------------------------- Edit ----------------------------------------
#Cipi: I'm not sure if this will work, but I can try. I think it will be the same problem though? I still see it happening like this:
User is already on one of my pages.
User clicks a link.
Browser starts fetching contents of new url, but the contents are simply an empty html file with just a javascript link in it.
After page is done downloading, browser renders the html (this is just a white screen).
Now the javascript starts executing in response to the onLoad() event(?), building the UI.
A few ms later, the DOM is done being manipulated, and is finally presented to the user.
so I am thinking that your solution would take place on #5, but by then the browser has already rendered the contents of the initial page on step #4?
#Crozin: I'm looking into DOMContentLoaded now, seems specific to gecko based browsers but there are solutions for ie etc. Yeah I basically want to manipulate the dom before the browser renders anything for the new page to screen, hopefully that can do it.
Thanks
Yes there are two methods:
Use DOMContentLoaded event
In the following code:
....
<p id="abc">abc</p>
<script type="text/javascript"> CODE HERE </script>
<p id="def">def</p>
Element with id abc is avaiable, but the one with id def ain't.