The Case for Profiles (Part 1)

I always kind of wondered about "perspectives" and their usefulness, i.e., whether there's any real relevance to them at all. Then, in discussion with two different groups of engineers, I finally "got it". Here are the scenarios/business requirements:

  • Admin-Driven Configuration Management. The application needs to have its layout configured by an administrator. The administrator should be able to create different profiles, e.g., per user, or per type of user, and then assign a different window layout to each profile. When a user logs into the application, the layout of the application will be fixed, determined by the profile that has been linked to their credentials. E.g., user "Peter" will be assigned to the "editor" profile, while user "Jack" will be assigned to the "viewer" profile. When they log in to the application, they will get a predefined window layout, defined by their profile, which they cannot change. I.e., after a user logs in, all the windows have fixed positions and cannot be dragged/resized/moved/etc.

  • User-Driven Configuration Management. The application is used in something like an air traffic control situation. The users spend many hours staring at the screen. To avoid falling asleep, they need to swap seats with a colleague. I.e., they change to a different computer every few hours, just to be in a new environment with a fresh view on things. When they get to their new computer, they need to be able to load their favorite window layout into their new work environment. They'll go to a "Profiles" menu item, or something like that, look in the list of available profiles and pick the one that they were using before. They shouldn't need to login to the application again, they should simply be able to select a different profile to the one currently in use and immediately they should then see their window layout return to their application.

In both cases, support for "perspectives" would be handy. In the "contrib" module, Anuradha has the source code of two modules. The first provides generic "perspectives" support, while the second provides "Java perspectives", i.e., it shows you how to register perspectives in the central registry so that the "perspectives" plugin can load them into the system.

Here's the source code for "perspective":

And here's the source code for "", which you can use as the basis for pre-registering your own perspectives:

For many developers with the above requirements for perspectives/profiles, the above code should be enough. However, in the next blog entries I will go step by step through both scenarios and show how the "perspective" plugin by Anuradha can be used to solve the business requirement.


I suppose this module has been made obsolete by the recent introduction of ("roles")?

Posted by Jesse Glick on June 09, 2011 at 01:04 AM PDT #

Wow, brilliant. That's fantastic. Several NetBeans Platform development teams will be happy with that.

Posted by Geertjan on June 09, 2011 at 03:52 AM PDT #

When changing roles, I can remove menu items via, for example, FileUtil.getCongfigFile("Actions/Window/<window>.instance").rename(flock, "<window>_hidden", "instance") (*)

but when going the other way, renaming away _hidden does not restore the menu item. What am I missing?

(*) flock details omitted to make pseudocode shorter.

Posted by guest on August 10, 2011 at 06:08 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed

Geertjan Wielenga (@geertjanw) is a Principal Product Manager in the Oracle Developer Tools group living & working in Amsterdam. He is a Java technology enthusiast, evangelist, trainer, speaker, and writer. He blogs here daily.

The focus of this blog is mostly on NetBeans (a development tool primarily for Java programmers), with an occasional reference to NetBeans, and sometimes diverging to topics relating to NetBeans. And then there are days when NetBeans is mentioned, just for a change.


« July 2016