LotusScript.doc v2 – an update on the progress

Besides working way too much I have spent a good part of my Holidays working on LotusScript.doc version 2 and I’m happy to say that it is very close to completion. I have spent a great deal of time finalizing the logging framework and building the Notes/Java bridge to allow you to run LotusScript.doc from a Notes database instead of as a command line program. I also needed to weed out some issues in this regard which is why I have been blogging issues such as configuring the java.policy file and the maximum Java heap size.

To clarify…

LotusScript.doc v2 is out in a very, very limited prebeta 1 with one person besides me to try and weed out the most serious issues before releasing a beta. Again a beta, at least the first, will only go out to a select number of people to try and keep track of who has what release.

The goals for the functionality of LotusScript.doc v2 are very big but for starters I’m going for feature parity with LotusScript v1. Then once the new technology is out there I’m going to start enabling the new and advanced features.

Thank you for your patience.

LotusScript.doc v2 – required Java heap changes

Strong: Just to clarify – LotusScript.doc v2 isn’t out yet. It is out in a very, very limited prebeta 1 (one person besides me) in preparation for a more general beta process hopefully in the very near future. See this post for a clarification on the progress.

As you might know LotusScript.doc v2 is written in Java instead of LotusScript. This means that you have to make some minor changes to your Notes client to make it work. One of the settings you need to change is the size of the Java heap that is the amount of memory allocated to Java objects.

To change that you need to set the JavaMaxHeapSize notes.ini parameter as described in the Lotus Notes and Domino wiki. Although the wiki describes the setting as only being applicable to Domino servers it works just as fine for my test Notes client (8.0.2 Standard in this case). To change the setting add the following to your notes.ini (do check whether it is already set):


LotusScript.doc v2 – java.policy changes required

Strong: Just to clarify – LotusScript.doc v2 isn’t out yet. It is out in a very, very limited prebeta 1 (one person besides me) in preparation for a more general beta process hopefully in the very near future. See this post for a clarification on the progress.

LotusScript.doc v2 uses java.util.logging as its underlying logging framework. To spice things up a little it also uses some internal magic to ease troubleshooting and provide easy debugging. One of these tricks is to print out the XPath expression of the element being processed in the log. More on this another time.

In order to use java.util.logging and set custom Handlers and Formatters you need to tweek the java.policy a little bit. It’s quite easy as the only thing you have to add to your <Notes binary directory</jvm/lib/security/java.policy file is the following in the first “grant” section:

permission java.util.logging.LoggingPermission "control";

Here is a link to a default java.policy file and a changed java.policy file.

Question on LotusScript.doc HTML output

I have been hard at work on version 2 of LotusScript.doc and I’m getting very close to a beta candidate. My main issue is that I keep adding features instead of finishing the core product as I now have a framework that is far more extensible than the version 1 code.

I’m currently finishing the framed HTML output that also shipped with version 1 and in that regard I have a question for LotusScript.doc users. Which parts of the HTML output do you actually use? In version 1 you could select to include the follow design element types and have output about these output to the documentation:

  • Script libraries
  • Agents
  • Database script
  • Forms
  • Views
  • Pages
  • Shared actions

Which parts do you actually use? Is there a better way to do it? Any parts that should highlighted differently?

Please donate

Based on prior and recent recommendations I have set up a Paypal account to accept donations to finance the development of the free version of LotusScript.doc version 2. All donations will be very much appreciated and help me justify the time I put into this.

It’s been quiet in LotusScript.doc land but…

…I have been hard at work and I’m getting close to a pre-release of LotusScript.doc v.2.

LotusScript.doc v. 2 is being completely rewritten from scratch (in Java), supports multi-threading and handles a wide array of new design elements compared to the 1.0.x code stream. The code and comment parsing is done and I’m currently working some of the more esoteric parsing bugs out.

One of the design goals for version 2 is also adding support for other output formats than the “traditional” framed HTML view. Writing custom output formats will also be possible using a template engine. I’m planning to ship the following documentation formats:

  • XML
  • Traditional framed HTML
  • A more comprehensive HTML report
  • PDF
  • DocBook

The main XML format is almost done and it’s what I wanted to show of today and is what I’m showing above. Click the image (or here) for a larger version. The larger XML snippet shows:

  • Ability to see which subforms are used from which forms
  • Ability to see which embedded views are used from which forms/pages and what their singlecategory formula is (if any)
  • Support for buttons (anonymous and named)
  • Support for actions (in action bar and as shared actions)
  • Ability to see which shared actions are used from which action bars
  • Support for subforms

The list of new features is quite a lot longer including vast performance improvements but lets not get carried away. Of cause the XML format will also carry the code comments.

Version 2

I’m starting to think of features and improvements for LotusScript.doc version 2 and was thinking what you had to say… What issues/problems do you have? What kind of features are you lacking? Please let me know so I might include them.

Please send comments and suggestions by e-mail to lekkim [at] lsdoc.org or as comments to this post.