I'm currently deciding between two different approaches for generating HTML with event handlers. I know both approaches are viable (I've seen both used before), but I'm unclear on their respective advantages, and since I'll be stuck with whichever one I pick I was hoping someone might be able to clarify those advantages for me.
Here's a simplistic example to explain the idea (although my real world cases will of course be more complex). Let's say we want to have a button that alerts "Hello Bob". The first approach is to use our view logic to generate the HTML, and then rely on a separate, high-level event handler:
$('body').append('<button class="nameAlert" data-name="Bob">Click me</button>')
$('body').on('click .nameAlert', function(e) {
alert('Hello ' + $(e.target).data('name'));
})
The second approach is to build an element object, bind a handler to it, and then append it to the DOM, all at once:
var $button = $('<button>Click me</button');
var name = "Bob";
$button.on('click', function(e) {
alert('Hello ' + name);
});
$('body').append($button);
There are some obvious advantages to the latter approach (eg. no writing data attributes, all the logic is one place) but I'm really curious about the non-obvious advantages (eg. the first version will perform better if we wind up with a lot of these buttons on the page). I'm especially interested in maintainability (that should be a programmer's first priority, right?).
Thanks in advance for any help.
I think what you are asking about is event delegation. Event delegation allows you to bind the event handler on a parent DOM element and handle events that occur within it. There are a number of benefits from this pattern, not the greatest of which is less repetitive code:
Efficiency. The browser does not have to attach event handlers to multiple dom elements.
Memory Leaks. It helps avoid memory leaks caused by dom elements being removed from the DOM that still have a javascript object referring to them. Since your parent element typically stays in the DOM as its children change, this doesn't happen.
Live binding. Event delegation will fire on any descendent node that matches the delegation selector, which means they can be added after the fact and still work.
I'm sure there are other benefits but those are some of the primary reasons for choosing event delegation.
I'm am pretty new to DOJO 1.8 and would like to know how I can call a function from outside a require-method? I try to implement a message-box which fades in and out.
I created the method:
require(["dojo/dom", "dojo/on", "dojo/domReady!" ], function(dom, on, ready) {
/*function which shows a msg-box on top of the page */
var showMsg = function(text) {
dom.byId("msgbox").innerHTML = text;
}
});
OK! IT works....but I no I would like to call it from somewhere else in my application:
showMsg("Item saved");
But that doesn't work: Uncaught ReferenceError: showMsg is not defined
How do I get that reference?
Thank you for your help!
AFX
As things stand you're declaring a local variable and so it's not visible elsewhere in the program.
You could make the variable global, for example
window.showMsg = function(text) {
dom.byId("msgbox").innerHTML = text;
}
The downside of this approach is that as you application gets bigger you end up with more and more global variables and that makes maintenance harder.
So Dojo offers ways to package chunks of reusable code and refer to them. You are already exploiting some of those capabilities when you use "require" - you're getting access to chunks of dojo. You can make your own code visible as reusable chunks in the same way.
This is quite a big topic, but you could start by reading this
Another thing you can do is to move the require inside the function.
Even if you have many such functions, while it's annoying to repeat, there is essentially no runtime penalty for requiring over and over. The only thing to watch for is that code inside the function becomes asynchronous, so instead of returning a value you have to use a callback or promise.
Alternatively, if you're only using this function from within some event handlers (I see dojo/on), you can set them up within the scope of this same require block.
First of all, I know there's libraries that provide polyfills for location.pushState/popState (History.js, Hash.js, jQuery hashchange), so please don't just link to those.
I need a more powerful library to achieve the following in a RIA:
User clicks a link
library is notified and loads context via Ajax (no complete reload!)
All <a> elements are leveraged with a click handler that
prevents page reloads in 2. (preventDefault) and
calls location.pushState instead / sets location.hash for older browsers
loaded content is inserted in page and replaces current content
Continue with 1.
Also, previously loaded content should be restored as the user navigates back.
As an example, klick through Google+ in Internet Explorer <10 and any other browser.
Is there anything that comes even close? I need support for IE8, FF10, Safari 5 and Chrome 18. Also, it should have a permissive license like MIT or Apache.
I believe Sammy.js ( http://sammyjs.org) (MIT-licenced) has the best focus on what you want to do, with its 2 main pillars being:
Routes
Events
I could quote from the docs but it's pretty straightforward:
setup clientside routes that relate to stuff to be done, e.g: update the view through ajax
link events to call routes, e.g: call the route above when I click an link. (You would have to make sure e.preventDefault is called in the defined event I believe, since this is an app decision really, so that can't be abstracted away by any library that you're going to use imho)
Some relevant docs
http://sammyjs.org/docs
http://sammyjs.org/docs/routes
http://sammyjs.org/docs/events
Example for a route: (from http://sammyjs.org/docs/tutorials/json_store_1)
this.get('#/', function(context) {
$.ajax({
url: 'data/items.json',
dataType: 'json',
success: function(items) {
$.each(items, function(i, item) {
context.log(item.title, '-', item.artist);
});
}
});
});
Or something like
this.get('#/', function(context) {
context.app.swap(''); ///the 'swap' here indicates a cleaning of the view
//before partials are loaded, effectively rerendering the entire screen. NOt doing the swap enables you to do infinite-scrolling / appending style, etc.
// ...
});
Of course other clientside MVC-frameworks could be an option too, which take away even more plumbing, but might be overkill in this situation.
a pretty good (and still fairly recent) comparison:
http://codebrief.com/2012/01/the-top-10-javascript-mvc-frameworks-reviewed/
( I use Spine.js myself ) .
Lastly, I thought it might be useful to include an answer I've written a while ago that goes into detail to the whole best-practice (as I see it) in client-side refreshes, etc. Perhaps you find it useful:
Accessibility and all these JavaScript frameworks
I currently use PathJS in one of my applications.
It has been the best decision that i have made.
For your particular usecase take a look at HTML5 Example.
The piece of code that that makes the example work (from the source):
<script type="text/javascript">
// This example makes use of the jQuery library.
// You can use any methods as actions in PathJS. You can define them as I do below,
// assign them to variables, or use anonymous functions. The choice is yours.
function notFound(){
$("#output .content").html("404 Not Found");
$("#output .content").addClass("error");
}
function setPageBackground(){
$("#output .content").removeClass("error");
}
// Here we define our routes. You'll notice that I only define three routes, even
// though there are four links. Each route has an action assigned to it (via the
// `to` method, as well as an `enter` method. The `enter` method is called before
// the route is performed, which allows you to do any setup you need (changes classes,
// performing AJAX calls, adding animations, etc.
Path.map("/users").to(function(){
$("#output .content").html("Users");
}).enter(setPageBackground);
Path.map("/about").to(function(){
$("#output .content").html("About");
}).enter(setPageBackground);
Path.map("/contact").to(function(){
$("#output .content").html("Contact");
}).enter(setPageBackground);
// The `Path.rescue()` method takes a function as an argument, and will be called when
// a route is activated that you have not yet defined an action for. On this example
// page, you'll notice there is no defined route for the "Unicorns!?" link. Since no
// route is defined, it calls this method instead.
Path.rescue(notFound);
$(document).ready(function(){
// This line is used to start the HTML5 PathJS listener. This will modify the
// `window.onpopstate` method accordingly, check that HTML5 is supported, and
// fall back to hashtags if you tell it to. Calling it with no arguments will
// cause it to do nothing if HTML5 is not supported
Path.history.listen();
// If you would like it to gracefully fallback to Hashtags in the event that HTML5
// isn't supported, just pass `true` into the method.
// Path.history.listen(true);
$("a").click(function(event){
event.preventDefault();
// To make use of the HTML5 History API, you need to tell your click events to
// add to the history stack by calling the `Path.history.pushState` method. This
// method is analogous to the regular `window.history.pushState` method, but
// wraps calls to it around the PathJS dispatched. Conveniently, you'll still have
// access to any state data you assign to it as if you had manually set it via
// the standard methods.
Path.history.pushState({}, "", $(this).attr("href"));
});
});
</script>
PathJS has some of the most wanted features of a routing library:
Lightweight
Supports the HTML5 History API, the 'onhashchange' method, and graceful degredation
Supports root routes, rescue methods, paramaterized routes, optional route components (dynamic routes), and Aspect Oriented Programming
Well Tested (tests available in the ./tests directory)
Compatible with all major browsers (Tested on Firefox 3.6, Firefox 4.0, Firefox 5.0, Chrome 9, Opera 11, IE7, IE8, IE9)
Independant of all third party libraries, but plays nice with all of them
I found the last too points most attractive.
You can find them here
I hope you find this useful.
i'd like to suggest a combination of
crossroads.js as a router
http://millermedeiros.github.com/crossroads.js/
and hasher for handling browser history and hash urls (w/ plenty of fallback solutions):
https://github.com/millermedeiros/hasher/
(based on http://millermedeiros.github.com/js-signals/)
This will still require a few lines of code (to load ajax content etc.), but give you loads and loads of other possibilities when handling a route.
Here's an example using jQuery (none of the above libraries require jQuery, i'm just lazy...)
http://fiddle.jshell.net/Fe5Kz/2/show/light
HTML
<ul id="menu">
<li>
foo
</li>
<li>
bar/baz
</li>
</ul>
<div id="content"></div>
JS
//register routes
crossroads.addRoute('foo', function() {
$('#content').html('this could be ajax loaded content or whatever');
});
crossroads.addRoute('bar/{baz}', function(baz) {
//maybe do something with the parameter ...
//$('#content').load('ajax_url?baz='+baz, function(){
// $('#content').html('bar route called with parameter ' + baz);
//});
$('#content').html('bar route called with parameter ' + baz);
});
//setup hash handling
function parseHash(newHash, oldHash) {
crossroads.parse(newHash);
}
hasher.initialized.add(parseHash);
hasher.changed.add(parseHash);
hasher.init();
//add click listener to menu items
$('#menu li a').on('click', function(e) {
e.preventDefault();
$('#menu a').removeClass('active');
$(this).addClass('active');
hasher.setHash($(this).attr('href'));
});
Have you looked at the BigShelf sample SPA (Single Page Application) from Microsoft? It sounds like it covers how to achieve most of what you're asking.
It makes use of History.js, a custom wrapper object to easily control navigation called NavHistory and Knockout.js for click handling.
Here's an extremely abbreviated workflow of how this works: first you'll need to initialize a NavHistory object which wraps history.js and registers a callback which executes when there is a push state or hash change:
var nav = new NavHistory({
params: { page: 1, filter: "all", ... etc ... },
onNavigate: function (navEntry) {
// Respond to the incoming sort/page/filter parameters
// by updating booksDataSource and re-querying the server
}
});
Next, you'll define one or more Knockout.js view models with commands that can be bound to links buttons, etc:
var ViewModel = function (nav) {
this.search = function () {
nav.navigate({ page: 2, filter: '', ... }); // JSON object matching the NavHistory params
};
}
Finally, in your markup, you'll use Knockout.js to bind your commands to various elements:
<a data-bind="click: search">...</a>
The linked resources are much more detailed in explaining how all of this works. Unfortunately, it's not a single framework like you're seeking, but you'd be surprised how easy it is to get this working.
One more thing, following the BigShelf example, the site I'm building is fully cross-browser compatible, IE6+, Firefox, Safari (mobile and desktop) and Chrome (mobile and desktop).
The AjaxTCR Library seems to cover all bases and contains robust methods that I haven't seen before. It's released under a BSD License (Open Source Initiative).
For example, here are five AjaxTCR.history(); methods:
init(onStateChangeCallback, initState);
addToHistory(id, data, title, url, options);
getAll();
getPosition();
enableBackGuard(message, immediate);
The above addToHistory(); has enough parameters to allow for deep hash-linking in websites.
More eye-candy of .com.cookie(), .storage(), and .template() provides more than enough methods to handle any session data requirements.
The well documented AjaxTCR API webpage has a plethora of information with downloadable doc's to boot!
Status Update:
That website also has an Examples Webpage Section including downloadable .zip files with ready to use Front End(Client) and Back End(Server) project files.
Notably are the following ready-to-use examples:
One-way Cookie
HttpOnly Cookies
History Stealing
History Explorer
There are quite a bit other examples that rounds out the process to use many of their API methods, making any small learning curve faster to complete.
Several suggestions
ExtJs, see their History Example, and here are the docs.
YUI Browser History Manager.
jQuery BBQ seem to provide a more advanced feature-set over jQuery.hashcode.
ReallySimpleHistory may also be of help, though it's quite old and possibly outdated.
Note: ExtJs History has been extended to optimize duplicate (redundant) calls to add().
PJAX is the process you're describing.
The more advanced pjax techniques will even start to preload the content, when the user hovers over the link.
This is a good pjax library.
https://github.com/MoOx/pjax
You mark the containers which need will be updated on the subsequent requests:
new Pjax({ selectors: ["title", ".my-Header", ".my-Content", ".my-Sidebar"] })
So in the above, only the title, the .my-header, .my-content, and .my-sidebar will be replaced with the content from the ajax call.
Somethings to look out for
Pay attention to how your JS loads and detects when the page is ready. The javascript will not reload on new pages. Also pay attention to when any analytics calls get called, for the same reason.
I cannot seem to force a layout in Swing. I have a JComponent added to a JLayeredPane and I set a border on the JComponent. Then, I want to immediately re-draw everything - not in the sense of "please do this asap" like invalidate(), but synchronously and immediately. Any help? I cannot seem to find the right method of doing this, and all my reading about invalidate(), validate(), repaint(), doLayout(), etc is just confusing me more!
According to this (see the section titled "Synchronous Painting") the paintImmediately() method should work.
The most reliable way to get Swing to update a display is to use SwingUtilities.invokeLater. In your case, it would look something like
SwingUtilities.invokeLater(new Runnable {
public void run() {
somecomponent.repaint();
}
});
I realize the 'invokelater' does not exactly sound like it does anything immediate, but in practice, events posted in this way tend execute pretty quickly compared to just calling e.g. somecomponent.repaint() directly. If you absolutely must make your control code wait for the GUI to update, then there is also invokeAndWait, but my experience is that this is rarely necessary.
See also: document on event dispatch in Swing.
This is super old, but I found a simple solution, which I'll show with a JPasswordField:
var pw = new JPasswordField();
...
pw.paint(pw.getGraphics()); // paints immediately
Explanation:
i have few objects and im declaring them inside $(document).ready(). WHY? because in thous objects i have many jquery methods $(..), obviously they can work outside too, but when i include mootool, then it stop working. i tried noConflict and some other things, nothing works, only if i change the $() to jQuery() or to $j().. and i dont want to change for my 20 files and more then 2000 lines for each file. anyway declaring my objects inside $(document).ready(). made them work just fine.
Now My Question is:
if i declare all these objects inside the $(document).ready() method, would it make my site slow? or would it make things slow from client side? thats the only concern in my mind.
I don't see how doing that would make your site slow. By declaring them within the $().ready you're simply restricting the scope of your declarations to that particular $().ready function, thus they won't be available from within the scopes of other ready functions on the same page - which should not really be a bother if your application is well-designed and you've stuck to one per page.
Oh, and your declarations certainly won't have been been parsed until the DOM is fully loaded, (as you know, $().ready only executes once the DOM has loaded), but that too should not be a problem as you're only utilizing them from within a ready function (at least I hope).
Do you really need two libraries? If it's just one or two little tidbits of functionality you are using from one of those libraries chances are you can mimic that behaviour using the one you're making the greatest use of. If you can possibly/feasibly do that it will make your life so much simpler.
Doing everything in jQuery.ready will not slow down your site.
As an alternative solution, you could replace $ with jQuery in all of your jQuery code, or you could wrap it in a function like this:
(function($) {
$('whatever').something();
})(jQuery);
This code makes a function that takes a paremeter called $, and calls that function with the jQuery object. The $ parameter will hide mootools' global $ object within the scope of the function, allowing you to write normal jQuery code inside the function.
Just declare
jQuery.noConflict before the document.ready request, then alias the jQuery method to $ within in the document.ready...
jQuery.noConflict();
jQuery(document).ready(function($){
});