The Artima Developer Community
Sponsored Link

Ruby Buzz Forum
Why you should be using History in your ExtJS applications

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
Edward Spencer

Posts: 148
Nickname: edspencer
Registered: Aug, 2008

Edward Spencer is a Ruby/Rails developer and the creator of the ExtJS MVC framework
Why you should be using History in your ExtJS applications Posted: Jan 23, 2009 8:57 AM
Reply to this message Reply

This post originated from an RSS feed registered with Ruby Buzz by Edward Spencer.
Original Post: Why you should be using History in your ExtJS applications
Feed Title: Ed's Elite blog
Feed URL: http://feeds2.feedburner.com/EdSpencer
Feed Description: Ruby on Rails development, Git issues and ExtJS/JavaScript
Latest Ruby Buzz Posts
Latest Ruby Buzz Posts by Edward Spencer
Latest Posts From Ed's Elite blog

Advertisement
I've been making a few updates to the ExtJS API documents application recently. The actual updates include remembering which tabs you have open and using Ext.History to go between tabs (you can follow the forum post or see a beta version).

That's not quite ready yet, but what has been made very clear to me is that any ExtJS application with more than one view should be using Ext.History. With History we get urls inside the application itself, we can parse them and dispatch accordingly. For example, I'm using a Rails-like Router, which lets you define an internal url map like this:


map.connect(":controllers/:action/:id");
map.connect(":controllers/:action");


The router knows how to decode urls based on the regular expression-like syntax above, and parse the matches into an object - for example:


#users/new <= becomes {controller: 'users', action: 'new'}
#users/edit/2 <= becomes {controller: 'users', action: 'edit', id: 2}
#colours <= becomes {controller: 'colours'}


You can of course define any url matching scheme using the connect() function. I then use a simple Dispatcher, which looks at the decoded parameters. It finds the appropriate controller and calls that action on the controller, passing any other parameters as arguments. For example:


#users/new <= calls UsersController's "new" action
#colours/edit/2 <= calls ColoursController's "edit" action, with {id: 2} as the argument


And so on. Each controller knows what to do for that action. It's easy then to say to someone "go to http://myapp.com/admin#users/152/comments" - which will take them straight to the comments that user 152 has written. Compare that with saying: "go to http://myapp.com/admin, then click the List Users tab, then find the user called Joe Bloggs, then double click the bubble icon next to his name". It's obvious which approach is better.

You don't even need to use something as elaborate as a router, just a simple switch statement or some regular expressions would be enough for many applications. Once you've got Ext.History setup, you could do something as simple as:


//decodes a url and decides how to dispatch it
dispatch = function(token) {
switch (token) {
case "users" : displayUsers(); break;
case "users/new": displayNewUser(); break;
case "users/2/edit: editUser(2); break;
default: displayDefault(); break;
};
};
Ext.History.on('change', dispatch);

//Call dispatch on initial page load as Ext.History's change event is not fired here
Ext.History.init(function() {
var token = document.location.hash.replace("#", "");
dispatch(token);
});


Obviously you don't hard code user IDs like that but it's easy to see how to roll your own. With just a few lines of code, you've decoded a url into a function to call, which can do anything you need it to. All your internal navigation needs to do is call Ext.History.add("some/new/url"), which will now be picked up by your dispatch code.

It's important to only route like this for idempotent actions (i.e. actions which display data rather than change it), so that data changing actions are not repeated. This is equivalent to using GET and POST correctly in normal web applications.

When the simplest implementation takes just a few lines of code, what reason could there be not to be using it?

Read: Why you should be using History in your ExtJS applications

Topic: Binary search an array in JavaScript Previous Topic   Next Topic Topic: Flex Code Folding In Amethyst

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use