Architecting your app in ext js 4, part 2 learn sencha

1/18www.sencha.com/learn/architecting-your-app-in-ext-js-4-part-2/

Architecting Your App in Ext JS Architecting Your App in Ext JS 44, , Part Part 22 Search

Twitter Facebook

Tumblr LinkedIn

RSS Feed Vimeo

42 Comments

Ext JS, v4.x

RSS | Responses

CommunityCommunity

Related PostsRelated Posts

The Sencha Class System

Nov 29

Architecting Your App in Ext

JS 4, Part 3 Sep 19

Ext Designer 1.2 Overview

Aug 4

Any ideasAny ideas??

If you have any ideas toimprove this article, please

let us know

11 TweetTweet 16

Published Aug 01, 2011 | Tommy Maintz | Tutorial | Medium

Last Updated Aug 10, 2011

This Tutorial is most relevant to Ext JS, 4.x.

In the previous Ext JS Architecture article, we explored how to architect a Pandora-style

application using Ext JS. We took a look at the Model-View-Controller architecture and how

to apply it to a relatively complex UI application that had multiple views and models. In this

article, we’re going to move beyond architecting the application visually, and explore how to

design and code the controllers and models, starting with Ext.application and the Viewport

class.

Let’s just jump in and start writing the application.

Defining our applicationDefining our application

In Ext JS 3, the Ext.onReady method was the entry point into your application, and the

developer had to come up with an application architecture. In Ext JS 4, we have an

introduced an MVC-like pattern. This pattern helps you to follow best practices when creating

your applications.

The entry point into an application written with the new MVC package requires that you use

the Ext.application method. This method will create an Ext.app.Application

instance for you and will fire the launch method as soon as the page is ready. This

essentially replaces the need to use Ext.onReady while adding new functionality such as

automatically creating a viewport and setting up your namespace.

appapp//ApplicationApplication..jsjs

Ext.application({

name: 'Panda',

autoCreateViewport: true,

launch: function() {

// This is fired as soon as the page is ready

}

});

The name configuration causes a new namespace to be created. All our views, models,

stores and controllers will live in this namespace. By setting autoCreateViewport to

true, the framework will, by convention, include the app/view/Viewport.js file. In this

file, a class should be defined with the name Panda.view.Viewport, matching the

namespace that was specified by the name configuration of your application.

4Like


The Viewport classThe Viewport class

When we looked at which views we needed for our UI, we were very focused on the

individual parts. The Viewport of an application acts as the glue for these individual parts. It

loads the required views and defines the configuration needed to achieve your app’s overall

layout. We have found that progressively defining your views and adding them to the viewport

is the fastest way to create the base structure of your UI.

It is important during this process to focus on scaffolding your views and not on the individual

views themselves. It’s almost like sculpting. We start by creating the very rough shapes of our

views and add more detail to them later.

Creating the building blocksCreating the building blocks

Leveraging the work we already did in the previous article, we are able to define many of the

views at once.

appapp//viewview//NewStationNewStation..jsjs

Ext.define('Panda.view.NewStation', {

extend: 'Ext.form.field.ComboBox',

alias: 'widget.newstation',

store: 'SearchResults',

... more configuration ...

});

appapp//viewview//SongControlsSongControls..jsjs

Ext.define('Panda.view.SongControls', {

extend: 'Ext.Container',

alias: 'widget.songcontrols',


});

appapp//viewview//StationsListStationsList


Ext.define('Panda.view.StationsList', {

extend: 'Ext.grid.Panel',

alias: 'widget.stationslist',

store: 'Stations',


});

appapp//viewview//RecentlyPlayedScrollerRecentlyPlayedScroller..jsjs

Ext.define('Panda.view.RecentlyPlayedScroller', {

extend: 'Ext.view.View',

alias: 'widget.recentlyplayedscroller',

itemTpl: '<div></div>',

store: 'RecentSongs',


});

appapp//viewview//SongInfoSongInfo..jsjs

Ext.define('Panda.view.SongInfo', {

extend: 'Ext.panel.Panel',

alias: 'widget.songinfo',

tpl: '<h1>About </h1><p></p>',


});

We have left out some of the configuration here since component configurations are not in

the scope of this article.

In the above configurations, you’ll notice that we have three stores configured. These map to

the store names prepared in the previous article. At this point we’ll go ahead and create our

stores.


The models and storesThe models and stores

Often, it is useful to start with static json files containing mock data to act as our server side.

Later, we can use these static files as a reference when we actually implement a dynamic

server side.

For our app, we decided to use two models, Station and Song. We also need three stores

using these two models that will be bound to our data components. Each store will load its

data from the server side. The mock data files would look something like the following.

Static dataStatic data

datadata//songssongs..jsonjson

{

'success': true,

'results': [

{

'name': 'Blues At Sunrise (Live)',

'artist': 'Stevie Ray Vaughan',

'album': 'Blues At Sunrise',

'description': 'Description for Stevie',

'played_date': '1',

'station': 1

},

...

]

}

datadata//stationsstations..jsonjson

{

'success': true,

'results': [

{'id': 1, 'played_date': 4, 'name': 'Led Zeppelin'},

{'id': 2, 'played_date': 3, 'name': 'The Rolling Stones'},

{'id': 3, 'played_date': 2, 'name': 'Daft Punk'}

]

}

datadata//searchresultssearchresults..jsonjson

{

'success': true,

'results': [

{'id': 1, 'name': 'Led Zeppelin'},

{'id': 2, 'name': 'The Rolling Stones'},

{'id': 3, 'name': 'Daft Punk'},

{'id': 4, 'name': 'John Mayer'},

{'id': 5, 'name': 'Pete Philly & Perquisite'},

{'id': 6, 'name': 'Black Star'},

{'id': 7, 'name': 'Macy Gray'}

]

}


ModelsModels

Models in Ext JS 4 are very similar to Records which we had in Ext JS 3. One key difference

is that you can now specify a proxy on your model, as well as validations and associations.

The Song model for our application in Ext JS 4 would look like this.

appapp//modelmodel//SongSong..jsjs

Ext.define('Panda.model.Song', {

extend: 'Ext.data.Model',

fields: ['id', 'name', 'artist', 'album', 'played_date', 'station'],

proxy: {

type: 'ajax',

url: 'data/recentsongs.json',

reader: {

type: 'json',

root: 'results'

}

}

});

As you can see, we have defined the proxy on our model. It is generally good practice to do

this as it allows you to load and save instances of this model without needing a store. Also,

when multiple stores use this same model, you don’t have to redefine your proxy on each one

of them.

Let’s go ahead and also define our Station model.

appapp//modelmodel//StationStation..jsjs

Ext.define('Panda.model.Station', {

extend: 'Ext.data.Model',

fields: ['id', 'name', 'played_date'],

proxy: {

type: 'ajax',

url: 'data/stations.json',

reader: {

type: 'json',

root: 'results'

}

}

});

StoresStores

In Ext JS 4, multiple stores can use the same data model, even if the stores will load their

data from different sources. In our example, the Station model will be used by the

SearchResults and the Stations store, both loading the data from a different location. One

returns search results, the other returns the user’s favorite stations. To achieve this, one of

our stores will need to override the proxy defined on the model.

appapp//storestore//SearchResultsSearchResults..jsjs

Ext.define('Panda.store.SearchResults', {


extend: 'Ext.data.Store',

requires: 'Panda.model.Station',

model: 'Panda.model.Station',

// Overriding the model's default proxy

proxy: {

type: 'ajax',

url: 'data/searchresults.json',

reader: {

type: 'json',

root: 'results'

}

}

});

appapp//storestore//StationsStations..jsjs

Ext.define('Panda.store.Stations', {


requires: 'Panda.model.Station',

model: 'Panda.model.Station'

});

In the SearchResults store definition, we have overridden the proxy defined on the

Station model by providing a different proxy configuration. The store’s proxy is used when

calling the store’s load method instead of the proxy defined on the model itself.

Note that you could implement your server side to have one API for retrieving both search

results and the user’s favorite stations in which case both stores could use the default proxy

defined on the model, only passing different parameters to the request when loading the

stores.

Lastly, let’s create the RecentSongs store.

appapp//storestore//RecentSongsRecentSongs..jsjs

Ext.define('Panda.store.RecentSongs', {


model: 'Panda.model.Song',

// Make sure to require your model if you are

// not using Ext JS 4.0.5

requires: 'Panda.model.Song'

});

Note that in the current version of Ext JS, the 'model' property on a store doesn’t

automatically create a dependency, which is why we have to specify requires in order to

be able to dynamically load the model.

Also, for convention, we always try to pluralize the store names, while keeping the model

names singular.

Adding the stores and models to our applicationAdding the stores and models to our application


Now that we have defined our models and stores, it’s time to add them to our application.

Let’s revisit our Application.js file.


Ext.application({

...

models: ['Station', 'Song'],

stores: ['Stations', 'RecentSongs', 'SearchResults']

...

});

Another advantage of using the new Ext JS 4 MVC package is that the Application will

automatically load the stores and models defined in the stores and models

configurations. Then, it will create an instance for each store loaded, giving it a storeId equal

to its name. This allows us to use the name of the store whenever we bind it to a data

component like we did in our views, e.g. store: 'SearchResults'.

Applying the glueApplying the glue

Now that we have our views, models and stores, it’s time to glue them together. You start by

adding the views one by one to your viewport. This will make it easier to debug any wrong

view configurations. Let’s go through the resulting viewport for the Panda app.

Ext.define('Panda.view.Viewport', {

extend: 'Ext.container.Viewport',

Your Viewport class will usually want to extend Ext.container.Viewport. This will

cause your app to take up all the available space in your browser window.

requires: [

'Panda.view.NewStation',

'Panda.view.SongControls',

'Panda.view.StationsList',

'Panda.view.RecentlyPlayedScroller',

'Panda.view.SongInfo'

],

We set up all the view dependencies in our viewport. This will allow us to use their xtypes,

previously configured in our views using the alias property.

layout: 'fit',

initComponent: function() {

this.items = {

xtype: 'panel',

dockedItems: [{

dock: 'top',

xtype: 'toolbar',

height: 80,

items: [{

xtype: 'newstation',

width: 150


}, {

xtype: 'songcontrols',

height: 70,

flex: 1

}, {

xtype: 'component',

html: 'Panda<br>Internet Radio'

}]

}],

layout: {

type: 'hbox',

align: 'stretch'

},

items: [{

width: 250,

xtype: 'panel',

layout: {

type: 'vbox',

align: 'stretch'

},

items: [{

xtype: 'stationslist',

flex: 1

}, {

html: 'Ad',

height: 250,

xtype: 'panel'

}]

}, {

xtype: 'container',

flex: 1,

layout: {

type: 'vbox',

align: 'stretch'

},

items: [{

xtype: 'recentlyplayedscroller',

height: 250

}, {

xtype: 'songinfo',

flex: 1

}]

}]

};

this.callParent();

}

});

Since Viewport extends Container, and Containers can’t have docked items (yet), we have

added a Panel as the single item of our viewport. We make this panel the same size as our

viewport by defining a layout of fit.

In terms of architecture, one of the most important things to note here is the fact that we have

not defined a layout-specific configuration in the actual views. By not defining properties like


flex, width, height in the views, we can easily adjust the application’s overall layout in

one single place, adding to the maintainability and flexibility of our architecture.

Application logicApplication logic

In Ext JS 3, we often added our application’s logic to the views themselves using handlers on

buttons, binding listeners to subcomponents, and overriding methods on the views when

extending them. However, just like you shouldn’t inline CSS styles in your HTML markup, it’s

preferrable to separate the application’s logic from the view definitions. In Ext JS 4, we

provide controlleres in the MVC package. They are responsible for listening to events fired

by the views and other controllers, and for implementing application logic to act on those

events. There are several benefits to this design.

One benefit is that your application logic is not bound to instances of views which means we

can destroy and instantiate our views, as needed, while the application logic continues

processing other things, like synchronizing data.

Additionally in Ext JS 3, you might have had many nested views, each adding layers of

application logic. By moving the application logic to controllers, it is centralized, making it

easier to maintain and change.

Finally, the Controller base class provides you with lots of functionality, making it easier to

implement your application logic.

Creating our ControllersCreating our Controllers

Now that we have the basic architecture for our UI, models and stores set up, it’s time to get

in control of our application. We planned to have two controllers, Station and Song, so let’s

create the definitions for them.

appapp//controllercontroller//StationStation..jsjs

Ext.define('Panda.controller.Station', {

extend: 'Ext.app.Controller',

init: function() {

...

},

...

});

appapp//controllercontroller//SongSong..jsjs

Ext.define('Panda.controller.Song', {

extend: 'Ext.app.Controller',

init: function() {

...

},

...

});

When including the controllers in your application, the framework will automatically load the

controller and call the init method on it. Inside the init method, you should set up listeners

for your view and application events. In larger applications, you might want to load additional

controllers at runtime. You can do this by using the getController method.


someAction: function() {

var controller = this.getController('AnotherController');

// Remember to call the init method manually

controller.init();

}

When you load additional controllers at runtime, you have to remember to call the init

method on the loaded controller manually.

For the purposes of our example application, we’ll let the framework load and initialize our

controllers by adding them to the controllers array in our application definition.


Ext.application({

...

controllers: ['Station', 'Song']

});

Setting up listenersSetting up listeners

Let’s start controlling some parts of our UI by using the control method inside of the

controller’s init function.


...

init: function() {

this.control({

'stationslist': {

selectionchange: this.onStationSelect

},

'newstation': {

select: this.onNewStationSelect

}

});

}

...

The control method is passed an object where the keys are component queries. In our

example, the component queries are just using the xtypes of our views. However, using these

component queries, you can target very specific parts of your UI. To learn more about

advanced component queries, you can refer to the API docs.

Each query is bound to a listener configuration. Inside each listener configuration, we want to

listen for the key which is the event name. The events available are the ones provided by the

component that is targeted by your query. In this case, we use the selectionchange

event provided by Grid (from which our StationsList view extends) and the select event

provided by ComboBox (from which our NewStation view extends). To find out which events

are available for a particular component, you can look in the events section available for

each component in the API docs.


The value in the listener configuration is the function that gets executed whenever that event

fires. The scope of this function is always the controller itself.

Let’s also set up some listeners in our Song controller.

appapp//controllercontroller//SongSong..jsjs

...

init: function() {

this.control({

'recentlyplayedscroller': {

selectionchange: this.onSongSelect

}

});

this.application.on({

stationstart: this.onStationStart,

scope: this

});

}

..

In addition to listening for the selectionchange event on our RecentlyPlayedScroller

view, we also set up a listener for an application event here. We do this by using the on

method on the application instance. Each controller has access to the application


0 0 CommentsComments

instance using the this.application reference.

Application events are extremely useful for events that have many controllers. Instead of

listening for the same view event in each of these controllers, only one controller listens for

the view event and fires an application-wide event that the others can listen for. This also

allows controllers to communicate with one another without knowing about or depending on

each other’s existence.

Our Song controller is interested in a new station being started because it needs to update

the song scroller and song info whenever this happens.

Let’s take a look at how the Station controller, which will be the one responsible for firing this

stationstart application event, actually does this.


...

onStationSelect: function(selModel, selection) {

this.application.fireEvent('stationstart', selection[0]);

}

...

We simply get the single selected item provided by the selectionchange event and

pass it as the single argument when firing the stationstart event.

ConclusionConclusion

In this article, we have looked at the basic techniques of architecting your application. Of

course, there is a lot to it, and in the next part of this series we will take a look at some more

advanced controller techniques and continue wiring up our Panda app by implementing our

controller actions and adding some more details to our views.

Written by Tommy Maintz

Tommy Maintz is the original lead of Sencha Touch. With extensive knowledge of Object Oriented JavaScript

and mobile browser idiosyncracies, he pushes the boundaries of what is possible within mobile browsers.

Tommy brings a unique view point and an ambitious philosophy to creating engaging user interfaces. His

attention to detail drives his desire to make the perfect framework for developers to enjoy.

Follow Tommy on Twitter

Share this postShare this post:: Leave a reply

Joel WatsonJoel Watson

Thanks so much for this article! I’ve been waiting a long time for a more

robust example of the MVC architecture in ExtJS 4, and it looks like we

finally have that!

While waiting for this, however, I’ve been trudging ahead, and it’s good to

see that this article is more of a substantiation of what I’ve already been

doing, rather than a complete overturning of it

Thanks again!

1 year ago

costacosta

Do you have any source code that I could run or look at?

1 year ago


Thanks

Yousif AtiqueYousif Atique

I am always glad to see a new tutorial/guide for ExtJS4. Much appreciate

this latest and greatest post around a much awaited topic of ‘architecting

ExtJS4 apps’. I understand that there has been another article around this

topic but was really looking for another one

Thanks

1 year ago

Tommy MaintzTommy Maintz Sencha EmployeeSencha Employee

@costa

The source code for the app will be available with the next part in the series.

The sample code already contains too much things that we haven’t

discussed yet.

1 year ago

Igor AstakhovIgor Astakhov

Why does your Application.js have properties or .stores .models instead of

the controllers

same goes for the viewport it requires the views and not the controllers..

What are the advantages of doing it this way rather then the other way?

1 year ago

Sean AdkinsonSean Adkinson

This is excellent. We plan on moving to Ext4 soon, and this MVC example

greatly helps me envision how our future application will act. I can’t wait!

1 year ago

LoianeLoiane

Best MVC example so far!

1 year ago

ykeyykey

Probably would have never thought to use application events that way.

Thanks for the article.

1 year ago

dbrindbrin

Well done Tommy! Thank you.

1 year ago

EdEd

Finally a thorough example! Thank you!!!

One question… you mentioned:

“The Application will automatically load the stores and models defined in

the stores and models configurations. Then, it will create an instance for

each store loaded, giving it a storeId equal to its name”

Does that mean every store and model throughout the application must

have a unique name? Or can we optionally use the fully namespaced

name?

1 year ago

Olivier PonsOlivier Pons

In your first code listing you wrote:

app/view/StationsList

1 year ago


It’s

app/view/StationsList.js

Alex LukinAlex Lukin

Well, this is good example, but what I really need is SIMPLE CRUD

example with delete and update operations and some server backend code

in Java or PHP or whatever. Could someone point me to such example?

1 year ago

disidisi

@Alex Lukin

As a starting point or a case study, you may be interested by ralphschaer

extdirectspring contribution:

http://code.google.com/p/extdirectspring/wiki/Changelog#1.0.11_-

_July_30,_2011

He recently published a maven archetype to create an app skeleton with

ExtJs4, Spring 3.1, Jpa, Hibernate and Spring Security

The learning curve may be steep, depending on your mileage and

background but as been gratifying in my case and eyes opener.

start from scratch in 3 steps

1

mvn archetype:generate

-DarchetypeArtifactId=starter-archetype

-DarchetypeGroupId=ch.ralscha -DarchetypeVersion=1.0.0

-DarchetypeRepository=http://ralscha.ch/archetypes

-DgroupId=com.mycompany -DartifactId=mynewapp -Dversion=0.0.1

2

copy extjs4 files as instructed

3

mvn jetty:run

The work is ongoing, bugs may still be left behind.

Enjoy,

PS: For others, please refrain whining before understanding the full scope of

the project, and if you find any bugs please contribute positively. The

owner/maintainer is responsive but I guess is doing this library on his spare

time.

Disclosure: I’m not affiliated with Ralscha and am currently using his library

in a small project and have only praise to his contribution

1 year ago

Sérgio MesquitaSérgio Mesquita

Thank you Tommy, for this tutorial. It help me a lot.

I look forward for the source code.

1 year ago


Just a suggestion: from a basic point of view, “model” is where you define

the data models, which means almost only columns definition, maybe not

the way data is fetched.

To keep this example simple, maybe adding a “default proxy” into the file

“app/model/Station.js” is too much, and may be disconcerting.

1 year ago

SonyaSonya

it’s very best example for understanding MVC in Extjs4

1 year ago


Igor AstakhovIgor Astakhov

From personal experience when having the proxy in the Store definition

instead of the Model you will run into deep waters with writers.

1 year ago

UserUser

Please release the source code ASAP. Seeing things in small chunks may

be helpful to some people but a working app that you can run an modify is

as good or better than any tutorial. Plus, you add in all the ellipses which

mess with the ability to properly create the files as you go along.

1 year ago

maduksmaduks

awsome!! at last some decent mvc example to follow and catch up with the

pro`s

1 year ago

Lazaros kosmidisLazaros kosmidis

First I’ll point my agreement with Igor’s ( Astakhov) comment (about the

proxy s) and Second a wish for a Direct implementation.(I’m currently

working on a variation (ExtDirect.php author J. Bruni) for ZendFramework )

Excellent job, should replace the equivalent source in Ext Docs. ASAP !!

1 year ago

Dan SantnerDan Santner

Excellent example! Thanks.

1 year ago

AA..TT..McClainMcClain

Great example. I have one small question on the code.

At the end of your viewport’s initComponent() call, you call the superclass’s

implementation with this.callParent(). In several of the other examples, the

arguments are also relayed to the superclass implementation via

this.callParent(arguments). What’s required or the best practice here?

Thanks! - ATM

1 year ago

VincenzoVincenzo

Is the “columns” definition mandatory for a Store?

1 year ago


Yes the “columns” definition is mandatory for a Store. It’s called “model”.

Example:

1 Ext.define(‘GS.store.Users’, {

2 extend: ‘Ext.data.Store’,

3 model: ‘GS.model.User’,

4 autoLoad: true,

5 proxy: {

6 type: ‘ajax’,

7 api: {

8 create: ‘/js/gs/app/data/users.json.php?

c’,

9 read: ‘/js/gs/app/data/users.json.php?r’,

10 update: ‘/js/gs/app/data/users.json.php?

u’,

1 year ago


11 destroy: ‘/js/gs/app/data/users.json.php?d’

12 },

13 reader: {

14 type: ‘json’,

15 root: ‘data’,

16 successProperty: ‘success’

17 }

18 }

19 });

VincenzoVincenzo

This is an incomplete example. This is an idea. This is a concept. Just now

it is something that feed condusion.

I think that a smaller working example would me more appreciated.

I will try to rearrange some Panel-Store-Model using this new paradigm. I

think it will not work.

1 year ago


Here’s my “app/model/User.js”

1 Ext.define(‘GS.model.User’, {

2 extend: ‘Ext.data.Model’,

3 fields: [‘id’,‘name’, ‘email’]

4 });

1 year ago

LoreZyraLoreZyra

I agree with the “User” above that requested “release the source code.” If

this were a class room, the code would be available in it’s entirety while the

instructor fed the students piecemeal. The more advanced students would

simply skip ahead.

So, why not offer the full source and then explain everything in sections (as

you have done above)?

1 year ago


Maybe because it’s not finished? Or not clean (yet)?

1 year ago

John WilanderJohn Wilander

I agree it’s frustrating not to have a working example to start from. Some

questions:

1. Should the viewport code go in the app/view/Viewport.js file as seen in

Part 1? It doesn’t really say but I guess so.

2. What’s with the this.callParent() in the Viewport? I get “Uncaught

TypeError: Cannot call method ‘getCount’ of undefined” when it’s called

(layoutCollection.getCount() on line 28500 in ext-all-debug). Maybe some

view configuration is missing?

Have anyone else here figured these things out? Thanks!

/John

1 year ago

ILIL

Controller and events fired by View is good.

But where’s the ROUTES?

How to response the back button on browsers, and other history changing?

12 months ago


SteveSteve

One thing I find very frustrating with ExtJs is that it seems like it has been

reserved for people with bigger smarter brains than mine and you guys

almost know that. Its like 5 steps to get your app up and running.

Step 1

Step 2

Step 5

What happened to step 3 & 4?

12 months ago

sakoleirosakoleiro

i`m waiting and waiting for new part

11 months ago

nextSTEPnextSTEP

Hi Tommy,

when will the next part be published?

11 months ago

drabslabdrabslab

Please release the source code, or has it already and did i miss it?

10 months ago

James PearceJames Pearce Sencha EmployeeSencha Employee

@sakoleiro, @nextSTEP, @drabslab - I recommend you sign up for our

newsletter (the signup, below here, to the right).

In the meantime, try changing the ‘2’ at the end of the URL to ‘3’

http://www.sencha.com/learn/architecting-your-app-in-ext-js-4-part-3

10 months ago

Casvan MarcelCasvan Marcel

Sencha Touch may be good, but your lack of documentation and

tutorials and good simple to understand examples make it sooo frustrating

to learn and use that the majority of programmers that stumble across it run

away from it. Until you change that fact, Sencha Touch will remain that

misterious application framework that most of us never managed to learn

and use. Reading on so many comments, I think I speak in the name of

everybody. I write this to you in hope that you’ll read it and do something

about it,and in the future we can actually use Sencha Touch in our apps.

Best regards

9 months ago


@Casvan Marcel: you’re perfectly right. I’ve given up on the MVC for now.

Maybe it should be better to have a binary behavior: either the full

documentation or nothing.

@James Pearce: I’ve tried changing the ‘3’ at the end of the URL to ‘4’ and

it gave me a 404

9 months ago

nextSTEPnextSTEP

There is no fourth part… so..?

9 months ago


You’re right, that’s what I meant: what’s the point of explaining something

and not finishing it?

9 months ago


Find Sencha developers at SenchaDevs © 2012 Sencha Inc. All rightsreserved.

Commenting is not available in this channel entry.

I’d better have nothing than just part 1, 2 and 3 without the most important

= part 4.

Chad WhitacreChad Whitacre

Loving the tutorial so far, but don’t JSON strings need to use double quotes

and not single quotes?

9 months ago

Sunil PratapSunil Pratap

Very nice examples and sample application to demonstrate the MVC

pattern in Ext JS4. I’m curious to know, how to implement a multi-module

application, which have separate entry point for each module and which

may or may not be linked together. Should we have the directory structure

like, Pandora/app/view/<module1>/<view files> etc. and

Pandora/app/<module-application.js>,

Pandora/app/view/<module1>/viewport.js to implement that and accordingly

use namespace for different components?

any help is greatly appreciable.

9 months ago

DonDon

Just wanna point out two mistakes. One filename is missing a .js at the

end. And JSON does not supports single quotes. http://jsonlint.com/

markes them as errors (and my ide too). JSON needs double quotes.

9 months ago

Architecting your app in ext js 4, part 2 learn sencha

Education

Transcript of Architecting your app in ext js 4, part 2 learn sencha