Base JavaScript versus jQuery example – Driving a DOM selector

One of the things a good web programmer should be able to do is write code using multiple libraries. In this case I have created two snippets that show how to select an HTML on a page using both bare-bones JavaScript and its corollary in jQuery.

The basic flow is:

MouseEnter Listener -> Modify border -> Click Listener -> Call Function

MouseOut Listener -> Restore border

This gives you an interface where you can then select a DOM element right from the web page. It would look like this:


Here are the two different implementations, you can see why I love jQuery, its brevity is breathtaking. The biggest difference is the selector API in jQuery that does the loop processing for you.

Base JavaScript

[codesyntax lang=”javascript”]

var all_1_Links = document.getElementsByTagName('div');
for (var i = 0; i < all_1_Links.length; i++) {
    var elm = all_1_Links[i];
    elm.addEventListener('mouseenter', function() {
        this.addEventListener('click', clickListener, true); =; = 'thin solid red';
    elm.addEventListener('mouseout', function() { =;



jQuery Version

[codesyntax lang=”javascript”]

$("div").mouseenter(function(e) { =;
    $("border", "thin solid red"); 
$("div").mouseout(function(e) { 



Brilliant selection UI!

I am not sure how many have watched the video links I referenced yesterday about the Dojo Web Builder but one thing I immediately noticed in the first video is the brilliant selection UI. I love how you select the different elements and the elements selected are shown in a side panel where you can remove them and reference what has been selected! Brilliant! I wish this was in Lotus Notes years ago when I would select many documents across pages of entries of a view and then wanted to copy them to a table. This kind of user interface would have been awesome.


Dojo Web Builder – Custom Builds from Dojo Toolkit on Vimeo.

The power of a community

Last week I posted an entry about Eclipse selection and when a view part should or should not process the selection.  I showed a pattern to use the IPartListener2 model as described in my post.  James Fry (no link provided) showed what now believe to be a much cleaner way to do this.  The reason its cleaner is because you are not on the part listener list and called every time and its a one liner!  No overhead of a boolean and your code to evaluate in the listener callback is now gone.  Much nicer!

Here was the code I ended up using:

if (viewer.getSite().getPage().isPartVisible(viewer) == false)

You should see this in the next release of the Attachment Viewer on OpenNTF.

Thanks James for being a reader and more importantly adding value to my blog!

One thing you may want to consider is when your view is re-opened or maximized you might want to restore the last selection so having a listener may be your only option in the end.

Eclipse selection and when to process or not

I heard from a user of the Attachment Viewer today that when a large ZIP was selected the client appeared to hang.  He explained that the attachment viewer was not even showing yet it looks like it still processed the selection.  Well, he was right.  After looking at the code, it was actually processing the ZIP file every time – whether the viewer was showing or not.  So I made a simple change and he is checking it out (testing it for me).  I did my small unit tests but I figured giving him a patch and testing his large ZIP file attachment would also be good – a second set of tests is always welcome in software.  🙂

So what did I do?

In the selectionChanged() event I had to determine if the view was visible or open.  This was an interesting problem because the view itself does not contain this state.  What I had to do was register the view with the workbench as an IPartListener2.  Why the “2” and not just IPartListener?  The key event we need is actually partHidden()!

The description of the event is here:

Notifies this listener that the given part is hidden or obscured by another part.

What I do is have a class level property named “_closed” and set it to true or false in the different events for IPartListener2.  This allows me to not process the selection if its “_closed” and just return out of the selectionChanged() callback.

I scoured the SWT and Eclipse world and I could not see another way to do this so if anyone has any input please let me know.  I will be updated the OpenNTF project with the fix in a few days.  I am sure one of the Eclipse guru’s reading would know if this is correct or not.

Eclipse Workbench Selection and Adapters and why they are so important

As more and more people are diving into Eclipse in the Notes community one very important area of the Eclipse workbench that needs to be understood is the Eclipse Workbench Selection and then more importantly Adapters.  Understanding these two basic concepts will let your Eclipse view (or component) interact with other Eclipse parts with no “wiring”.  The workbench selection is a fixed pub/sub where your component will be notified any time another part changes its selection – a workbench window only has one selection at a time.  This allows your view part to show relative information to the new selection.  The Adapter pattern explained in the linked article explains how you can provide selection objects that can be adapted to other well known object types.  It also shows you how you can adapt an existing selectable object type to something else.

Many of the side bar components that work off of a currently selected email or document use this pattern.  This allows your side bar component to be able to respond to what is currently selected.

Adapters article on

Do you want XPage components in the side bar?

Looks like I lost two posts when they moved my blog between servers!  I am going to post these back here.  For this specific one,  if you answered prior that you would like this can you please do it again.  There was a request for what customers would want such a thing.

One of the biggest wins for Lotus Notes at Lotusphere was the fact that XPages can run in the 8.5.1 client.  You can, in that release, also have XPages as components in composite applications.  This also means you can have XPage components in the side bar and somewhat standardize XPage technology as your component UI technology but it needs to be in a composite currently.  This is all great but one piece of feedback was “How do I just put an XPage widget in the side bar without being in a composite?”.  The question was intriguing because it also exposed another gotcha.

There are two primary use cases for having something always live in the side bar:

  1. Just live there and be available for a specific function.
  2. Interact with the currently selected context – ie. respond or show information based on a view selection or tie an event into a Live Text action.

The first one would work fine, the second one would not work today.  The problem is, there is no “Workbench Selection” or “Selection” event in an XPage today.  We would also have to standardize on serialized workbench selections – objects that can be sent over a pipe or use JSON.  As for Live Text integration – this would also be a feature request to get this integration into Widgets (or Toolbox).

I would like to hear the thoughts of my readers on this.  I do understand many are just getting into XPages and components but it would be interesting to hear from the community their take on this.

Extending Notes with new view context menus and text selection context menus

Over the last few weeks I have received several Eclipse questions for how business partners and customers can extend Notes 8 in new ways.  The following two posts should answer some of those questions.  The first post shows how you can extend the right click menu for a text selection in a Notes document while the second post explains how you can extend the right click menu in a Notes view entry.

How to extend the right click text selection menu in a Notes Document

Adding right click options to your Notes 8 mail box entries with Eclipse