Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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
   }
})
like image 825
reagan Avatar asked Oct 05 '22 14:10

reagan


2 Answers

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.

like image 171
sra Avatar answered Oct 10 '22 03:10

sra


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!

like image 42
dougajmcdonald Avatar answered Oct 10 '22 01:10

dougajmcdonald