What is ExtJS philosophy? Single page application? [closed]_问答_开发者

Closed. This question needs to be more focused. It is not currently accepting answers.

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 4 years ago.

Improve this question 开发者_如何转开发

I need to write my next project using ExtJs. It's a nice Javascript lib but I don't fully understand the idea behind it. Take the docs page for example.

Am I supposed to write my web applications with extjs like that? One page that should never be refreshed, and everything getting done by AJAX?

How do you debug such applications if getting to the right place may take a lot of 'clicking' and working with it. You cannot fix the bug and hit refresh in the browser to see the results.

Any suggestions?

Am I supposed to write my web applications with ExtJS like that? One page that should never be refreshed, and everything getting done by AJAX?

You don't have to write your applications like the ExtJS documentation. If you look at the example pages for ExtJS you'll see a lot of HTML mixed in with Ext widgets on individual pages. In my work I have two different apps that I'm using ExtJS on, one is a legacy site where I use the widgets to spruce up the pages, and the other is a full blown web application using nothing but ExtJS for the front end. I definitely prefer the latter once I got a hang of it, but the learning curve is pretty steep.

How do you debug such applications if getting to the right place may take a lot of 'clicking' and working with it.

The key here is to modularize your application. Build each component individually and test it in a vacuum. Don't get caught up into thinking this has to be some giant JavaScript file that contains the entire application. In most web apps the source had dozens or more JavaScript files which are only combined for deployment purposes.

A must have for testing and debugging is firebug. It allows you to inspect Ajax requests, debug the JavaScript live and much much more.

Here's a series of articles about composing large Apps using ExtJS, it a pretty decent read with a lot of good info.

Building a sample application in ExtJS 4 Part1 Part2 Part3

For ExtJS 3.3 and below Part1 Part2 Part3

I think it's ok to use ExtJS in either way, if you're just getting started it might make more sense to do what you're most comfortable with and add some ExtJS 'spice' along the way. That said, once you start using it to create single page apps and you have your back-end outputting nothing but JSON you'll probably never look back at the old way you did web apps.

You could do what modern AJAX-based apps do and use the URL hash to deep-link your app.

Gmail is a great example of how this works. To get to my inbox, I navigate to:

https://mail.google.com/mail/?shva=1#inbox

To go to my contacts manager I browse to:

https://mail.google.com/mail/?shva=1#contacts

Both of these "pages" are on the same page, and navigation ever actually redirects me to a different page while I use the app. The hash is all that changes.

When the page loads, what you need to do is check window.location.hash and use that to update your app's state.

Not single-page but few paged application

I was involved in a complex project that was built on:

Asp.net 3.5
WCF web services
ExtJS 2.1
.netTiers (with CodeSmith) for DAL + DAO
SQL 2005 + OLAP Cubes (some don't-remind-me-of-this-nightmare workarounds had to be done within the app because we used some third party controls, that partially supported UpdatePanels and this thing alone broke the very basic processing of our application)
custom look and feel over the existing ExtJS - this was the hardest part of ExtJS costumization so I suggest you stick to one of the provided themes

We didn't do actual single-page application but it's true that the number of pages was greatly reduced. Each area of work within the application was usually a separate page. All interface processing was either done on the client using ExtJS or on the server side within WCF services that provided data to ExtJS client interface.

It worked great.

I'd probably change one thing today: I'd migrate from Asp.net + WCF to Asp.net MVC. It's more build for this kind of scenario.

With regards to debugging we used Firebug (Firefox plugin) extensively just like any other developer would do.

But using ExtJS library was a great success. It made it easily possible to create desktop-like data heavy web application. It's a great unified library for any professional intranet web application development. With jQuery and it's plugins you are always left alone with different quirks of those plugins that community provides. ExtJS is very unified in this regard and provides a really nice look and feel out of the box.

I think that is the idea, to, in some way, match the desktop feeling of applications in a web environemnt, that means almost everything works with Ajax.

As for the debugging, firebug is your friend. But it shouldn't be that different to debug a desktop application where also a lot of clicking might be involved to get the bug.

You can use something onHashChange listener, together with what I call "closure" format for loading extjs screen. I wrote an article about how to build a single page extjs application.

In terms of testing ExtJs...

Here is a testing tool that tests ExtJs components (this tool was made with ExtJs!)

Siesta Testing Tool to test ExtJs

I haven't personally used this myself yet but I had a look at the demo video and it seems pretty sweet!

Perhaps community members might know any alternative tools that specifically test ExtJs?

PS: I am in no way connected to Sencha (ExtJs) or Bryntum (Siesta). I use ExtJs at a customer level.

You don't have to write like that. Sometimes it looks nice that way and faster (no refreshes for new pages).

You can do automated recordings for javascript that do your stuff with some automated testing tools or writing those things yourself. Usually debugging the whole page is not that good idea. When it's built up modularly it's easier. Isolate the problem and it's easier.

Also consider using firebug for debugging it might help you out.

Suggestion: I depends what are you doing. If you're making highly interactive page then it might be a good idea to do it that way. It's faster and ajax requests can be lower load on the server. On the other side it's going to take more time to do that way.

I am using ASP.Net MVC with ExtJS. It is not one page application, but it is close, it feels like one page app.

and also we have a web forms application with hundreds of pages, we applied some ExtJS UI widgets on this app, using a lot of IFrames, it still works and looks great. But I don't enjoy using web forms model, and try to avoid it as much as I can.

IMHO;

asp.net mvc platform would be better than webforms platform.
Controllers fit very well for action handling.
Partials are usefull to generate html content (scaffolding helps a lot here)

ExtJS

for navigation,
listing,
searching,
editing content,
notification,
pretty much for everything else...

overall ExtJS is a great framework.

In our application we wrote a custom Page class that handles the switching between "pages". All a Page consists of is an ExtJS container that returns your classes, and we keep history by setting #hash values on the end of our URL.

Using this approach you load your ExtJS library once along with all assets, which pays huge dividends for performance as well as keeping your app fluid.