Wednesday, May 25, 2011

Xpages - Java Bean lessons of the day

This Xpages stuff is still fairly new to me and there are lots of little things I struggle with. Today was spend trying to figure out how to build some of the log-in/log-out logic. For a couple of problems I could not find a direct answer on the internet, so I thought I'd share what I came up with.

Remove a bean from the session

In the application I'm building there's this "User" bean that holds all kinds of user data and provides some application logic. When the user clicks the log out button, it would be neat to cleanup that bean. The following line of SSJS code removes the "User" bean.

facesContext.getExternalContext().getSessionMap().remove("User");

Invalidate the session

Another option for the log-out cleanup function is to invalidate the whole session, which you can do with the following line of SSJS code:

facesContext.getExternalContext().getSession(true).invalidate();

Of course, this cleans up a lot more than just the User bean.

Read property from resource bundle

In the beans, you would of course like to use the resource files. It's easy. Put the following Java method in a Utils class:

public static String getResource(String bundleVar, String name) {
 XSPContext xspContext = XSPContext.getXSPContext(FacesContext
   .getCurrentInstance());

 try {
  // There has to be bundle defined with var name 
  ResourceBundle bundle;
  bundle = xspContext.bundle(bundleVar);
   if (bundle != null) {
   return bundle.getString(name);
  }
 } catch (IOException e) {
  e.printStackTrace();
 }

 return "";
}

And call it as follows:

Utils.getResource("settings", "db_users");

For reference, "settings" is the name of the bundle resource and "db_users" is the name of the setting. From the theme configuration:


 
  /WEB-INF/settings.properties
  settings
 


Get a request variable

The User bean does some auto-login magic. To be able to do that it needs to read the request cookies. No problem! Take this static function, put it in some Utils class:

Utils.getCookies();

public static String getCookies() {
 // System.out.print(XSPContext.getXSPContext(
 // FacesContext.getCurrentInstance()).getUrl());

 HttpServletRequest request = (HttpServletRequest) FacesContext
   .getCurrentInstance().getExternalContext().getRequest();
 return request.getHeader("cookie");
}

You can modify this to read other request parameters, to extend the handling of cookies, etc..

Have fun!

Sunday, May 15, 2011

Bulk cleanup old Working Set databases, part 2

Earlier today I wrote a post describing how you could cleanup the Working Set by editing the XML that stores the Working Sets. I stated that you cannot do this though the Package Explorer view, as a delete from the view would also remove the database. That turns out to be wrong and thanks to Nathan Freeman for pointing it out.

When you delete an entry from the Package Explorer view, it asks for confirmation and displays a checkbox with "Delete project contents on disk". I thought it was about cleaning up the temporary database files in de workspace folder and checked the box. But I was wrong. Checking this will tell Designer to actually remove the database, the .nsf.

Of course, I had to test it before correcting my previous post. During testing I made a couple of screenshots which I will present below. The testing was done on my development server with four blank databases named Test 1 up to 4.

On the left you see the four databases in the Working Set "Test". To the right the contents of the workspace folder (note the four folders with temporary files for the Temp databases) and at the bottom the four databases on the server.

From the Package Explorer the four databases are selected. Note that only one database was actually opened.

After clicking on "Delete", the confirmation dialog is presented. Make sure to not select "Delete project contents on disk".

After clicking OK, you see the database entries have been removed from the Test Working Set (top left), temporary files have been removed (top right), but the .nsf's are still available on the server (bottom right). Alright, that's what we're looking for!

Now a test to see what happens when you do select the "Delete project contents on disk" checkbox. I re-added the four databases to the Test Working Set, selected them in Package Explorer and clicked in the context menu on "Delete". Of course, selecting the checkbox before hitting OK.

After clicking OK, the databases have been removed from the Working Set, temporary files have been removed from the Workspace folder and, most importantly for this test, have been removed from the server

The delete in the Package Explorer turns out to be pretty powerful. You can use it to quickly cleanup your Working Set, but also to remove the corresponding databases. All from without the Domino Designer environment. Pretty cool, thanks Nate for pointing this out!

Bulk cleanup old Working Set databases (updated)

Updated 15-05-2011 20:35: As Nate commented, it turns out to be possible to bulk-select-and-remove database entries from the Working Sets with the Package Explorer view, without actualy removing the .nsf's themselves. Please read the new post.

Domino Designer's Workings Sets are a great help in the life of a Lotus Domino developer. They make switching between projects a lot easier and up your productivity. But after a while they become cluttered with databases you might not be working on anymore.

Cleaning up from either Designer's Application view or the "Managing Working Sets" popup can only be done one database at a time. And it's a slow process, not something you'd want to full your working day with. The Package Explorer view does support a multiple-select and delete, but that action will not only remove the Working Set reference, but also delete the Notes/Domino database itself!

If you're not afraid of editing XML by hand (if you are, you are probably reading the wrong blog), my previous blog post on recovering Working Sets can help. The Working Set databases are stored in an XML file in your Notes Data directory:
notes\data\workspace\.metadata\.plugins\org.eclipse.ui.workbench\workingsets.xml
You can open the XML file in an editor (Notepad++ is my favorite) and remove unwanted databases. Make sure you close Domino Designer before you start editing. Also, please pretty please, make a backup from the workingsets.xml file first and/or use a decent backup program (I still recommend CrashPlan+).

Note: As far as I know this will not remove the data that has been stored on disk in the notes\data\workspace directory, so you might want to clean that one up to.

I've heard managing Working Sets will be approved upon in an upcoming version of Designer. But until then, you can do it by hand and save yourself a lot of time.

Wednesday, May 11, 2011

Recover Designer Working Sets

If your Domino Designer environment is as stable as mine, you loose your precisely crafted Working Sets at least once a week. I still do not know why Designer is as instable as it has been the last few weeks, but at least I have found a way to recover a lost Working Set. Hooray!

The first step is to make sure you have a backup of the notes/data directory. I recommend CrashPlan+. The family plan is hard to beat in price if you have more than one computer or a couple of VM's. It allows you to do offsite cloud backups, with up to 10 computers, unlimited in size. Additionally, you can backup to a local drive, NAS or friends computer (free, free, free). There's no excuse not to do backups.

With that out of the way, the Working Sets are stored in a file in your notes/data directory:
notes\data\workspace\.metadata\.plugins\org.eclipse.ui.workbench\workingsets.xml
Each time Domino Designer starts up with blank Working Sets,  close Notes and Domino Designer, restore the file mentioned above from your backup system and start Notes / Domino Designer.

Game on!