Many thanks to John Mackey:

http://www.jmackey.net/groupwareinc/johnblog/johnblog.nsf/d6plinks/GROC-7G9GT4

and to Daniele Vistalli http://factor-y.com for this idea, for their help and the great powers.

Since Domino 8.5 is Eclipse based, you can switch to the Java perspective and add Java code to your project. The nsf database is the project.  (If you haven't done this yet, it is interesting to switch perspectives and look around at the structure and the code.)  By switching to the Java perspective, you open up your code to the importing or referencing of Java libraries, or the creation of your own classes.

Now we investigate how to create PDF using XPages. This tutorial summarize John's article, with some other things that you have to pay attention to.

Step by step.....

package mypackage;
import java.io.FileOutputStream;
import java.io.IOException;
import com.itextpdf.text.Paragraph;
import com.itextpdf.text.pdf.PdfWriter;
/**
* First iText example: Hello World.
*/
public class Test {
      public static void createPdf(String filename) throws Exception {	
       try {
            Document document = new Document();
            PdfWriter.getInstance(document, new FileOutputStream(filename));
            document.open();
            document.add(new Paragraph("Hello World!"));
            document.close();
        } catch (Exception e) {
            e.printStackTrace();
        }
     }
}

• select the project and then select Project->Properties from the menu (or right click)
• select the Java Build Path and click on Add Folder button.  Select the new source folder.  Click OK.
• In WebContent\WEB-INF add the folder called lib
• Right-click on it and select Import->File System->Browse and select itext jar (i.e iText-5.0.2.jar)
• import itext jar (i.e iText-5.0.2.jar) in your Java Build Path:  Project->Properties->Java Build Path->Libraries->Add Jar and select jar from WebContent\WEB-INF
• Note: you have to deploy jar in your server, in data\domino\java and append this line in notes.ini, JavaUserClasses variable

JavaUserClasses=......;C:\Programmi\IBM\Lotus\Domino\data\domino\java\iText-5.0.2.jar

this will not cause security problem when you call iText methods to generate PDF

function create(){ 
        mypackage.Test.createPdf("hello.pdf");
}

create();

That's all!

The APIs we want

We must reach this:

$(...).maxLinesLengthBound(n)
$(...).maxLinesCountBound(n)
$(...).maxTextLength(n)

Obviously, we like jQuery chaining so also this must work:

$("#textareaid").maxLinesLengthBound(20).maxLinesCountBound(15)

All of the 3 new jQuery feature take all the textarea element from the expression given and apply new bounds.

• The maxLinesLengthBound method will put a limit on the number of lines in a textarea
• The maxLinesCountBound method will put a limit in the number of characters of each line
• The maxTextLength method is the most simple: put a limit to the number of total character in textareas

Bad news one: Javascript events

When adding character in Javascript we can rely on 3 events:

• keydown event is called when a key is pressed (before it's released)
• keyup event is called when a key came up after keydown.
• keypress event is called when a key is... pressed! So it goes down and then up. More important, if you keep pressed a button, starting the characters-repeat, this even is called multiple times.

As you can see, the keypress is the best choice... but using this event has a great limitation.

When you rely on keydown event, the "actual" value of the field is the old one. When you bind an handler to the keyup or keypress events the value you can read is the new one. You have no way to know what was the old value of the field.

Don't think to use other events like change event. This type of event has the same problems and also is called only when the control loose focus.

Solution to bad news one

Yes, we can only read the new value of the field, but we can also use the event object and take from it the value of the pressed key, so we can know what new character will be added to the textarea

Bad news two: knowing where the cursor is (on Internet Explorer)

Unluckily in a textarea you not always append characters... you can also add new characters inside the text. The pressed key is still a very important resource, but we must also know in which position we are inside the textarea.

The task seems simple on all browsers, with only a single exception: you can read the selectionStart attribute of the textarea DOM element.

We really need this only for one of the 3 APIs we need above: the maxLinesLengthBound method. Other 2 APIs don't need to know where the cursor is...

The vary bad news is this: Internet Explorer do not support selectionStart!

Solution to bad news two (AKA: bad news three)

You can surf the Web looking for an alternative, and you will find a lot of blog post, articles and script for giving an alternative.

What is clear is that you must use some funny IE specific APIs like getBookmark and createRange... and you will fail.

I found no way to really have the same simple features. On Internet Explorer 7 I have a lot of problems when I go to the second line. Those APIs seems buggy and the browser don't see that you go on a new line.

Tired of this, I leave the problem to someone more expert than me with IE Javascript.

Wanna help me?

The jQuery plugin

You can find the plugin on the jQuery plugin official page, and also other info and the SVN repository in my Google Code space.

Sometimes, for some reason, you have to do it. I'm talking about the use of System.setProperty() method within a java agent. If you don't pay attention it's easy to get a null pointer as result. Infact I got it. 

After a quick search I found out a way to solve the issue:

I will use "jna.library.path" as example.

First of all add the following line in "java.policy" file (in the "jvm\lib\security" folder below the Domino program folder).

permission java.util.PropertyPermission "jna.library.path", "read,write";

After that, add the java code to your agent :

String jnaProperty = "jna.library.path";
if(System.getProperty(jnaProperty) == null) {
   System.setProperty(jnaProperty,"your path");
}

In one of our projects we are still using Plone 3.1.x. with a pack of customer specific content_types and some additional PAS plugins (Lotus). I have noticed recently that calling invokeFactory become VERY slow. After debugging we have found the problem - getDefaultAddableTypes - method that is provided by constraintypes.py (ATContentTypes package). Original implementation is more then 4 years old. What it does - it checks isConstructionAllowed for every content_type register in portal_types. If you have registered them more then 40 ;-) ...

In most of the cases folderish types are filtering allowed_types. Thanks to Vincent we have now a nice fix:

Modified lib/constraintypes.py:getDefaultAddableTypes method to check isConstructionAllowed only for allowed types, not for all content types in portal_types. isConstructionAllowed was called twice for each types.

This fix is in ATContentTypes version 1.3 and started to be used by Plone 3.3.1. For us it was a good argument to upgrade!