Open Source
InformAI allows AI to access and understand the information in your React components
→ Read moreReadNext creates AI-powered content recommendations for your blog or other content
→ Read moreI'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:
The router knows how to decode urls based on the regular expression-like syntax above, and parse the matches into an object - for example:
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:
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:
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?
For a deeper understanding of how to implement history management in your applications, check out Using Ext.History, which provides a step-by-step guide on integrating browser navigation features into your ExtJS apps. Additionally, you might find ExtJS modules and mixins helpful for learning how to encapsulate common functionality and enhance code reusability in your projects.
On January 1st 2010 I officially joined Ext JS to take over the role of lead developer. After livin
A few days back Praveen Ray posted about 'Traits' in Ext JS. What he described is pretty much what
Just as with Jacky's session, I didn't plan on making a separate post about this, but again the cont