Dynamic Remote XUL, Struts, and Java Server Pages

I've recently had the opportunity to use Mozilla's XML-based XUL user interface language for the frontend of an Apache Struts application. The idea consists of using Firefox tabs or XUL tabs to manage multiple windows in the application.

Is it a Browser or a Client-Side Application?

Essentially, the application will run in a Firefox browser; however, it will look like a client-side application. That is the beauty of XUL. Since the Firefox user interface was developed using XUL, applications written in XUL can "take over" the Firefox interface and integrate with it either partially or fully. Thus, the line between what components are Firefox and what components belong to the application is very thin.

The backend will be developed in Java and use Struts to help utilize a Model, View, Controller architectural pattern. We are breaking new ground here. Most Struts applications I've seen generate dynamic HTML, not XUL. The application will be served remotely, appear to be a client-side application, and use Struts Action classes as the controller.

Since Struts actions are called via url's, it's possible to have different parts of our application run in different Firefox tabs! Mozilla has an API that allows developers to interact with the browser. Using JavaScript, a developer can open a url in a new window, a new tab, or the current window. From a development perspective, this means we can force our different modules to run in different tabs. The application would essentially run not in one Firefox tab, but in multiple tabs.

XUL Tabbrowser

There's not a lot of information out there on Struts and XUL, but it appears to be a very scalable model in that the MVC framework means that even existing Struts applications could be retrofitted with XUL simply by modifying the view.

However, the lack of Mozilla documentation does present a challenge. I found information on the tabbrowser XUL element, but none of the information appeared to be correct. In addition, the Mozilla Developer Center API for tabbrowser was missing examples. After researching and testing a solution, I contributed the following example:




<vbox>
  <tabbox id="tabBrowser">
    <tabs>
    <tab label="Tab1"/>
    <tab label="Tab2"/>
    <tab label="Tab3"/>
   </tabs>
  <tabpanels width="500" height="500">
    <browser id="browserTab1" src="http://www.mozilla.org"/>
    <browser id="browserTab2"/>
    <browser id="browserTab3"/>
   </tabpanels>
  </tabbox>
  <hbox>
   <button id="btnLoadBrowserContent"
  label="Load URL"  oncommand="loadURL(document.getElementById('tab2'),'http://developer.mozilla.org')"/>
 </hbox>
</vbox>


The example above will display three tabs in a Firefox window. Each tab contains a browser object. Using XML DOM methods, the src attribute can be dynamically modified based on user or system events:

function loadURL(browserElem,pUrl) {
//modify the src attribute of the browser element
browserElem.setAttribute("src",pUrl);
}

The JavaScript code above will modify the src attribute of the second browser object and cause a page to be loaded in that tab. By replacing the src attribute with different Struts action urls, this application will be extremely dynamic and scalable.

Multiple HTML Reply Signatures for Gmail

I've upgraded the HTML Reply Signatures for Gmail script. The Multiple HTML Reply Signatures for Gmail Greasemonkey script does the following:

1. When the user composes or replies to a message, an HTML signature is inserted in the Gmail editor by default.

2. At any time before pressing 'Send', the user can select another HTML signature from the drop down list in the left navigation menu of Gmail.

Multiple HTML Reply Signatures for Gmail Demo

1 Personal Signature
2 Work Signature
3 Other 1
4 No Signature

Hello,

This is a demo Gmail content window that demonstrates the plug-in behavior of the Multiple HTML Reply Signatures for Gmail script. Use the drop-down list on the left to toggle between different signatures.

--

I've also addressed issues regarding the HTML signature placement. This script places the signature at the end of the reply, not at the end of the thread. I've noticed that the subject of HTML signature placement is a hotly debated topic. However, my reasons for placing the HTML signature at the end of the reply are as follows:

1. I find that I rarely, if ever, scroll through quotes from previous emails in a thread unless I need to refresh my memory; therefore, I find that I am less likely to see a signature that is at the bottom of the thread.
2. After several replies back and forth, signatures will begin to accumulate at the bottom of the thread. Because of reason #1, none of these signatures will be seen anyway, unless I need to reference an earlier part of the conversation. If I do scroll to the bottom, I'll see multiple instances of my signature and that of the person I've been collaborating with.
3. Keeping the entire message content at the top of a reply helps identify the boundary of where one message ends and another begins. Placing the signature at the end of the reply clearly identifies where the end of the reply is and where the previous email begins.

However, I realize that there are people who will disagree and insist that the HTML signature be placed at the bottom of the thread. If you want to move the HTML signature to the end, by all means, go for it. It is actually easier to code the script so that signatures are placed at the end. So, if you need help with this modification, let me know.

It is also worth noting that the dropdown list can be configured to plug in different signatures for replies than for initial composes; however, the drop down list values will be the same. What this means is this: I can configure a "Personal Signature" for replies and a "Personal Signature" for initial composes. Likewise, I can configure a "Work Signature" for initial composes and a "Work Signature" for replies. I can also set them to be the same. However, in any case, the dropdown list values will always be the same.

Finally, the script can be configured to insert no HTML signature by default. As long as the htmlsignature and/or htmlreplysig variable has a beginning span tag with an id="image_sig" and a closing span tag, anything, including whitespace, can be placed in the innerHTML. Once an HTML signature is selected from the dropdown list, only signatures from that list can be selected. Therefore, it is important to ensure that the default HTML signature is also in the dropdown list. It is for this reason that the fourth option in the dropdown list is configured as "No Signature", which sets the innerHTML to whitespace. Therefore, if a user decides not to use an HTML signature after selecting one, it can be removed by selecting this option.

In order to use this script, you must have Mozilla Firefox 1.5 or higher and the Greasemonkey firefox extension installed. If you've already installed Firefox and Greasemonkey, you can go ahead and install the Multiple HTML Reply Signatures for Gmail script.


UPDATE: The script is now available as a Firefox Extension!