CODEWITHSUNDEEP
javascriptmodel-view-controllerextjsextjs4.1extjs-mvc
reagan
reagan

Reputation: 131

Extjs4 mvc design ideas

I am still learning Extjs and mvc so I have a design question that I am sure someone can answer for me. My question is:

I have 2 controllers that handle two different views. Either of the two controllers are called to render the correct view based on the type of user. So in my case if the user is admin then they will get the admin view based on credentials and if the person a standard user then they will get the standard view. Should the decision logic be placed in the app.js or should there be another controller that decides which controller to call?

One way I am thinking about:

controller for admin

Ext.define('adminController', {

      // handles admin 
})

controller for standard user

Ext.define('standardController', {

      // handles standard 
})

App.js 

   Ext.application({
   name: 'MTK',
   autoCreateViewport: true,

     if(admin) {
       controllers: ['adminController']
     }
     else(std){
       controllers: ['standardController']
     }
});

Another idea:

controller for admin

Ext.define('adminController', {

    // handles admin 
})

controller for standard user

Ext.define('standardController', {

    // handles standard
})

main controller

Ext.define('mainController', {

   if(admin){
      call adminController
   } 
   else(std){
      call standardController
   }
})

Upvotes: 5

Views: 329

Answers (3)

arshabh
arshabh

Reputation: 166

I think as sra rightly pointed out, let the server send you the right information about the type of user logged in. At the client side let one controller decide which view to render. This should be the same controller handling the login page. CARD VIEW is the layout that you can use in this purpose. after the page is rendered let the other controller take care of the events fired in that view

And any ways controller should not do the render part that is the work of view use the controller only for reacting to the events fired in the view

Upvotes: 0

dougajmcdonald
dougajmcdonald

Reputation: 20037

Interesting question, I agree with @sra that it's not perhaps the right way to do this via client side logic although it's not to say it wouldn't work.

In an app I've been working on we've used the approach of defining all controllers which may or may not be called in a 'nav' style controller. This is the only one we directly instantiate and then based on firstly defaults and then, direct interactions we chose to render appropriate controllers and views which is kind of like the second approach @sra suggested.

I think sra's first approach is sensible in general, but the issue comes when you perhaps have one view which as an admin should be editable and as a user should be read only. You don't want to be writing two views in this situation.

One thing I haven't tried (but this question has made me want to!) is to return either a) a slightly different model based on server side logic, like a 'user' or 'readonlyuser' and pop that into the same view (to save needing two views) or b) to return a more complex model with each data property accompanied with say an 'editable' flag. This could then be used to render different fields, or fields in different modes in the app.....I'm aware this doesn't answer the question, interested in the approach you choose and any findings you care to report though!

Upvotes: 2

sra
sra

Reputation: 23975

I wouldn't do (or at least too much of it) this in the frontend. I guess you should be able to know the user role the time the user is logging in so.

For me I do it this way, but I must say I have a much more complex ACL and I won't bother a user with modules or views where the backend will refuse any access to.

I am using these two approaches:

  • reload/redirect to the application view (backend!) after a successful login. The server knows what to hand-back by the user session
  • return a configuration after a successful login witch contains information what to require next (this could be just a controller or some more classes)

Both approaches result in less code, faster loading's and easier debugging

I hope this points you in the right direction.

Upvotes: 2

Related Questions