bookmark_borderQUINDIP: set JAVA Compiler target in notes.ini

Literally EVERY time I created a Java agent or library the compiler target was set to 1.2 even though I have been using LN 7 or later…
I always had to find the noteId and use a tool to manually change the source and target to 1.6.

here’s how you can change that behaviour:


AND make sure you add an EMPTY at the end in case JavaCompilerTarget=1.6 is your last line! otherwise this setting will not be used!

bookmark_borderYOUFEB: anyone else being mad about the copy&paste (via keyboard / not working in designer?

I am getting over and over mad that copy & paste is not working well at all in the LN designer especially when dealing with xPages stuff..

I add a template inheritance to a design element, select it, copy via <ctrl><c> and paste it onto another design element, either I get something pasted i copied long time ago, or nothing at all.

so I have to revert to right click copy and right click paste..

this annoys me a lot.. is it just me or anyone else facing the same issue?

bookmark_borderFRULE!!!: 9h to find ignoreRequestParams=”true” needs to be set!!!

In continuation of this I faced another problem in my target database. The first time the dialog for the sensitive data was called, it worked just fine. All subsequent calls just failed. After a very long time (you know it………) I finally figured out: the dialog box was using the parent document in subsequent calls.. but why? And why did it work on my test application.

With help from a coworker I finally, by accident!, figured the only difference between test and my actual database was ignoreRequestParams=”true”!! On test this parameter was set and there it worked. I gave it a try, without actually knowing what I was doing. Why I didn’t know? That’s a rhethorical question, right? 😉 On the web I have been stumbling across some other blogs mentioning it, which might have been the reason why I, ghosted  as I was through the lack sleep, tried it out on test. I honestly don’t know how that parameter came there.

But what the heck… finally my approach worked and I could save all my special infos with special access rights to another document!

Anyone: Would it be possible for someone knowing in detail what this parameter is about to write about it? Would be highly appreciated.

What I then figured was also very interesting in itself: Even though the “events” for the data source were not “visible” in the events viewer they were available! Under all properties etc.. you will find it:

That’s by the way also the place where you can toggle the flag for “ignoreRequestParams”!
The cool thing with those events: my defined document datasource is acting like an xPage in itself! Means I can change fields, run my custom validation approach etc. to my liking. Really neat!

bookmark_borderQUINDIP: how to set field values with java (or DominoDocument the magic animal)

Old approach:

   XspInputText field = (XspInputText) StandardUtil.findComponent(facesContext .getViewRoot(), “countryName”);

The annoying thing about this approach: You never know exactly which class the component has, ie. a “read only” field is not XspInputText etc., and thus you cannot just use this approach really transparently.

New approach:

DominoDocument dominoDoc = StandardUtil.getDominoDocument();
dominoDoc.replaceItemValue(“editableField”, new Date().toString());

It works for editable/hidden/disabled/readOnly fields!!!

And the best thing is: you do not even need to know the fields xPage name anymore! 

You only care about set in the binding property. This in effect speeds up development a lot, cause I do not need to check/modify field names in 2 places anymore.

the getDominoDocument works like this:

DominoDocument dominoDoc = (DominoDocument) JSFConnector
return dominoDoc;

and the JSFConnector you will find here (kudos to Karsten Lehmann)

bookmark_borderquindip: debugging java in xPages made simple (four steps)

for some of you this might be the almost perfect XMas gift from me.

I finally figured how to debug Java code in an xPage application, and it’s DEAD SIMPLE…

if only more people would blog about it…

so here is how:

1. Create a debug configuration. The debug button might not always be visible, you will see it definetely by switching to the Java perspective.

2. add those 2 lines to your notes.ini and restart your notes client/designer
3. set any break point
4. do anything on an xPage which goes to Java, say using a Managed Bean or call a method from a normal Java class and voilà the debugger activates and you can check your code..
Most probably the first attempt will result not result in actually seeing code… you might get this result:
don’t desperate, click the button and then add your project and you will see your code… 
I wonder why IBM does not promote this VERY VERY VERY publicly… you have to again.. by accident stumble accross a video from Niklas Heidloff (kudos to him) 
this will save me soooooooooooooooooooooooooooooooooooooooooooooooo many headaches!!!