Hi
this is not related to xPages but to LotusScript:
we have started years ago to use “kind-of” javadoc-ish style of documentation of our code:
really neat 😉
enjoy
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:
http://www-10.lotus.com/ldd/ddwiki.nsf/dx/07152009034956PMMSTR75.htm
enjoy
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!
did you ever happen to notice this nice little “filter” field on the top right hand side of the LN designer when in a list of design elements?
really neat!
if only I could access it via keyboard, any ideas?
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?
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:
Be honest! Do you hate this little crappy editor “window” too?
But here’s what I do:
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.
addendum:
the getDominoDocument works like this:
DominoDocument dominoDoc = (DominoDocument) JSFConnector
.getVariableValue(“currentDocument”);
return dominoDoc;
and the JSFConnector you will find here (kudos to Karsten Lehmann)
To speed up debugging you can use step filters. Step filters effectively filter out all classes you are not interested in while you debug.
Use step filters:
Setup step filters (in preferences):
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.
Did you know that you can drag&drop in the applications view design elements from one application to the other?
you can actually “drop” them anywhere on the target application and they are put in the proper place.
