Subscribe to comments directly from FeedDemon – nice!

Isn’t that cool! A way to directly subscribe to the comments to a specific post directly from the RSS reader (FeedDemon in my case). Sweet! I took a look at the RSS feed source and it is due to the use of the Comment API (http://wellformedweb.org/CommentAPI/) and the <wfw:commentRSS /> tag. This is a new feature added in FeedDemon 2.0.24 just out…

Java in Notes/Domino Explained: Test agents in Eclipse by extending AgentBase (part 1)


This post way sparked by a post in the Notes/Domino forum on developerWorks.

Let me start by saying that you could probably use the AgentRunner if you can figure it out and if it still works. I haven’t used it for a LONG time and I doubt that it still works with the changes made to the Java API in Notes/Domino 6.x and 7.x. The Using Document of the AgentRunner database hasn’t been updated since 1999!! Anyways – there are other options.

Write the code in a separate class hierarchy

The first one is to write the agent functionality in separate classes and then have the agent code call these classes to do its job. This is a viable approach though it means you have to maintain the actual business code and the agent code in separate places (the business code in Eclipse and the agent code in Notes/Domino).

Extend lotus.domino.AgentBase

Another option is to extend the AgentBase class and implement some of the intializing functionality yourself for testing. The approach isn’t optimal and still makes you implement some boilerplate code but it’s a start and a viable option for writing and testing your agents in Eclipse. The new AgentBase class can be made to detect whether it runs inside Eclipse or inside Notes/Domino so it’s easy to move the code into Notes/Domino once it works.

The boilerplate code has to do with initializing a thread to Notes in a main() method before calling the NotesMain() method of your agent class. The below example shows the required boilerplate code for the ExampleAgent1 class:

public static void main(String[] args) {
   try {
      NotesThread.sinitThread();
      new ExampleAgent1().NotesMain();

   } catch (Exception e) {
      e.printStackTrace();
   } finally {
      NotesThread.stermThread();
   }
}

The new AgentBase class (called EclipseAgentBase) means you can write agents in Eclipse. The only change is that you extend EclipseAgentBase instead of AgentBase:

import lotus.domino.NotesThread;
import lotus.domino.Session;

public class ExampleAgent1 extends EclipseAgentBase {

   public static void main(String[] args) {
      try {
         NotesThread.sinitThread();
         new ExampleAgent1().NotesMain();

      } catch (Exception e) {
         e.printStackTrace();
      } finally {
         NotesThread.stermThread();
      }
   }

   public void NotesMain() {
      try {
         Session session = this.getSession();
         System.out.println("Username: " + session.getUserName());
      } catch (Exception e) {
         e.printStackTrace();
      }
   }
}

In the next part of the post I’ll dive into how do build the EclipseAgentBase class.

XInclude

As previously mentioned here and here I’m using external entities at present to redue the amount of dublicate data when sharing data among XML documents. A better choice than entities would be to use XInclude which is a recommendation from W3C on how to include XML documents in other XML documents. The difference betwwen entities and XInclude is that XInclue is an extension to the core XML and that it integrates nicely with the other XML extensions such as XSLT. An example of using XInclude is show below:

<code>
  <xi:include href="MyFile.xml" />
</code>

Unfortunately XInclude isn’t supported in the LotusScript XML classes – probably because it’s only a recommendation. It isn’t supported in the Java included in Notes/Domino either since Notes 7 has Java 1.4.x which in turn has JAXP 1.2 (Java API for XML Processing) which is too old. XInclude is however included in JAXP 1.3 so if you need it you can upgrade your XML processing libraries to the latest Xerces from Apache.

A caveat might be however that Notes/Domino is shipped with a combined Xalan (XSLT) and Xerces (XML parser) library (/jvm/lib/xml.jar). I haven’t tried updating this library but would like to hear from people having tried. An alternative is off cause to include the new xerces.jar in the agent or similar so the new classes are used.

Resources:

Inside The Net 24: The Two Mikes from Firefox

The new episode of the Inside The Net podcast is about Firefox and the Two Mikes. Show description from the TWIT homepage: “Hard on the heels of the successful launch of Firefox 1.5 comes the first beta of Firefox 2.0. Mike and Mike talk about Firefox Flicks and what’s new in 2 including lookahead searching, RSS support, and faster browsing.”

Show ‘n Tell Thursday: Using XSLT on DXL documents (8 June 2006)


Using XSLT on XML is a great way to filter the data before parsing the result document. With DXL this is even more true to the VERY verbose nature of DXL. An advantage of using XSLT to filter the DXL document before parsing is that it is much easier to filter based on XPath queries rather than walk the DOM tree or using SAX parsing and writing and handling all the events that would arise from parsing a DXL document.

If you are not familiar with XPath or XSLT I suggest you read up on the technologies. Although I haven’t used the tutorials myself the tutorials provided on w3cschools.com tends to be quite good. At the site you’ll find tutorials on both XPath and XSLT.

I would also like to plug my upcoming article in the May/June issue of THE VIEW where I also discuss this subject and how I used the techniques in LotusScript.doc… 🙂

Well basically using XSLT with DXL is quite simple if you know how (isn’t everything). The only caveat is that you have to remember that the DXL documents exported from Lotus Notes use the dxl-namespace so you’ll have to import the namespace and use the namespace in all XPath queries. Normally a XSLT stylesheet starts like this:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">

When using XSLT on DXL documents you’ll have to import the dxl-namespace as well (change in bold):

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                xmlns:dxl="http://www.lotus.com/dxl" version="1.0">

Once you have done this you can use XPath as normally and make your templates match their target. The below example will create a bullet list of the script library names from a complete export of a Notes database (notice the use of the dxl-namespace in bold):

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet
     xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
     xmlns:dxl="http://www.lotus.com/dxl"
     version="1.0">
     <xsl:output method="html" version="1.0" encoding="iso-8859-1" />

     <xsl:template match="/">
       <ul>
         <xsl:apply-templates select="/dxl:database/dxl:scriptlibrary" />
       </ul>
     </xsl:template>

     <xsl:template match="//dxl:scriptlibrary">
       <li>
         <xsl:value-of select="@name" />
       </li>
     </xsl:template>

</xsl:stylesheet>

Applying the above style sheet to an export of the LotusScript.doc database will produce a bullet list like the one below:

  • CLASS: Script
  • CLASS: ScriptParser
  • CLASS: ScriptElement
  • CLASS: Collections
  • CLASS: InputStream
  • CLASS: ScriptFactory
  • CLASS: OutputStream
  • CLASS: DocumentationWriter
  • CLASS: Index
  • CLASS: OutputStreamFactory
  • CLASS: ClassHierarchyIndex
  • CLASS: ScriptSource
  • DBDesign
  • CLASS: DocumentationBuilder
  • CLASS: LSDocConstants
  • CLASS: Comment
  • CLASS: DecisionMaker
  • CLASS: ConfigDocuments
  • CLASS: TemplateVersion

An easy way to test XSLT style sheets if you do not have an IDE capable of helping you is to associate the style sheet with the DXL document and then preview using a browser. To see how see my post called Apply XSLT style sheet to an XML document for browser friendly display.

Hope the above helps someone…

Domino SuperSearch

In the June issue of the LotusUserGroup.org Developer Tips Newsletter Duffbert writes about the Domino SuperSearch over at martinscott.com. Although a nice application what if the we had an application like that which also searched through all the blogs listed at dominoblogs.com? Wouldn’t that be cool and a nice way to “take a penny, leave a penny”? 🙂

If dominoblogs.com emitted an OPML file it could be consumed by a site that allows users to search the sites. Only issue I can see it the difference between search interfaces but it could be solved by people also submitting a search URL to the dominoblogs.com site.

What do you think?