The Case for Profiles (Part 2)

Going on from yesterday, let's start by looking at the first scenario. If you log on as an administrator, you need to be able to configure profiles, each consisting of a window layout, for standard users. If you log on as a standard user, you shouldn't be able to change the window layout, in fact, the window layout should be assigned to you based on who you are.

We'll not deal with all of the above scenario this time round, just the first part. I.e., based on your login, you can be enabled to configure the window layout.

Here's the login:

If the above is entered, i.e., admin/admin, the following is shown, i.e., the Profiles menu, and the windows can all be moved around to create profiles (i.e., "perspectives", introduced in yesterday's blog entry):

However, if "admin/admin" is not entered, there's no "Profiles" menu and the window layout is fixed, i.e., notice no "x" buttons to close the windows, for example:

How to configure your application to allow for the above two different set ups? Here's the key, in the "branding" folder of the application, create two new files, next to the existing "" file that contains a list of properties for enabling/disabling window system features:

In the "", I have this:


In the other one, i.e., "", I have the same keys, all set to "false".

Now I create a login screen, as discussed elsewhere, inject a layer, as also discussed elsewhere, to dynamically add the Profiles menu for the administrator, and then I switch branding. So, here's the only new bit:




The above two are called depending on whether "admin/admin" is set (the first one) or not (the second one). That's all, now your branding is set dynamically and the window layout is either feature-rich or fixed.

Next, we'll look at the perspectives created by Anuradha's module, how to persist them into a database, and how to match them to a user and load them on demand.


Using the branding dir of your suite this way does not work, because the result is a file modules/locale/org-netbeans-core-windows_student.jar with entries,, and (every $n.$e file is replaced with $n_student.$e), so NbBundle.getBundle("...Bundle") with branding set to "student_admin" will look for, not find it, then load To fix, you would need to create a separate source tree (not ${basedir}/branding) for each nondefault branding (using unsuffixed filenames inside), then override the 'branding' target to call <branding> on these in addition to the primary branding.

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

Just beware of:

Posted by Jesse Glick on June 09, 2011 at 04:58 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.


« November 2015