Questions about components..

[shinji666]

I'm working on a web base application using flex with multi user levels. Different user levels will have different UI. I'm having some issues about components life cycle as the user logs off. Right now it seems that i have to manually revert back to the default view and destroy the opened components when user click log off. I was wondering if this is the best practice? Can such call be avoided (i.e. many components)? Is there a better approach than this?

[Barna Biro]

It really depends on how your application will look like. If "different UI" means "different skins" then you can keep your components and only play around with the styles. In case "different UI" would mean new components, things that maybe a user has, another one hasn't and who knows what... then you might not be able to avoid the call.

You can maybe avoid a "complete call" by keeping the components that are common among users and only changing their style/state ( this way, you don't need to remove and re-add the component, you can simply "update it" ).

Design patterns could come in really handy in such situations. In case you are not familiar with the MVC ( Model-View-Controller ) meta-pattern then you might want to read up on it ( I'm quite sure you'll find it interesting ).

In essence, solutions always exist... but since you are the person with the most information regarding the project, only you can make certain decisions ( or try to provide more detailed information and we might help you out with a few hints on how to structure the application... but we really need more precise details in order to provide advices that can actually help ).

Best wishes,
Barni

[shinji666]

Hi Barni,

Currently i have some the common components shared by different user permission levels and update them when there's a user change. No issue in that aspect. However, in the case when there's a module that not every users will able to use, I have to manually destroy them when logging off. So i was wondering if there would be a more efficient way to handle this type of situation.

As I expand the web application, more and more module will be unique to specific user levels. It seems that i have to manually track such initialized component module and destroy in the event of log off. I'm not sure if that would be the best design?

[Barna Biro]

Well, if that's the case the destroying is somewhat inevitable. One thing I do not understand is why are you destroying to components at log off? Why aren't you instead checking and destroying at log in... since it's possible that the same user will log back in so there would be no need to destroy components.

In case a new user logs in and you want certain modules not to show, then I can't really think of any better solution than checking and destroying the unwanted modules. If the log in page would have been totally separated from the application then this destroying problem would have not occured because the newly logged user would have loaded the application from beginning and you could have enabled the components specific to the current user's permissions level. Once logged off, the user is redirected to the separate login page and the cycle starts over again.

From what I understand that you have there, I can't really think of a different solution than destroying unwanted modules ( but I'd do this on user Log In and not log off ). If the application would have been built differently, then maybe we could have found a more "straight-forward" solution without having to check for unwanted modules and stuff.

[JeTSpice]

i worked on an application that had a few tiers of permissions. we just bound visible to the permission and it worked quite well. there was little overhead.

possibly do this for now. And if need be, optimize later.