inMood – Page 6 – Shared experience around development topics

QUINDIP: SOLVED!!! that damn DominoDocument IS a WILD AND MAGICAL thing!!!

Posted on 2013-04-01 by admin

Wow…

So here’s what I learned:

notes objects usually can’t be serialized. For some stupid reason I came accross the DominoDocument.wrap method and thought: let’s give it a try!! You bet: You create a “manual” DominoDocument with it and it can be serialized.

Exactly this technique now helps me to dynamically display RT fields (actually MIME entities to be correct so far, but I think it’ll work for RT as well) as tooltips:

Resulting code:

<xe:tooltip id=”tooltip4″ dynamicContent=”true” for=”someLabel”>
<xp:inputRichText id=”inputRichText1″
readonly=”true”>
<xp:this.value><![CDATA[#{javascript:doc = database.getDocumentByUNID(‘someUNIDToADocumentContainingTheBodyField’);
dominoDoc = com.ibm.xsp.model.domino.wrapped.DominoDocument.wrap(null, doc, null, null, false, null, null);
dominoDoc.getValue(‘Body’)}]]></xp:this.value>
</xp:inputRichText>
</xe:tooltip>

CRYFH: how can I bind a richtext field with javascript?

Posted on 2013-04-01 by admin

Maybe it helps to have some knowledgeable readers, let’s see.

What I would like to achieve:
Have tooltips displaying RichText fields (defined as “help documents”).

This works for just 1 tooltip: I define a document data source and simply bind the RT field on the xPage to the docSource.Body, voilà!

Now:
Of course I do have multiple places where I would like to display such a fantastic tooltip!

Tooltips indeed are “dynamic”.

Using this code I get the subject from the help document back no problem:

database.getDocumentByUNID(‘someUNID’).getItemValue(‘Subject’)

using the same code (trying to retrieve the RT item) I simply get back the item’s name!!

What do I miss?

What I tried, but also didn’t work: to change the docSource dynamically, ie. having the tooltip change the UNID of the docSource and then simply bind as described above with docSource.Body. But I couldn’t manage to get the dynamic tooltip to “refresh” the docSource.

Any ideas?

CRYForHelp

QUINDIP: format your custom type aheads properly

Posted on 2013-04-01 by admin

Did you read my blogs about cool type ahead features? really cool type-ahead and making type-ahead easy as pie.

Here’s the sequel on how to make the “custom” type-ahead also look really nice.

Java code to create custom type-ahead:

StringBuffer sb = new StringBuffer(“”);
StringBuffer sbNames = new StringBuffer(“”);
Session session = (Session)DominoUtils.getCurrentSession();
Database db = (Database) DominoUtils.getCurrentDatabase();
View view = db.getView(“lupCountriesByUNID”);

// apply the search, this can be anything, looking up by key and NOT forcing a match
// or an FT search, we use for different amount of characters different fields to search in
// 2 characters = ISO language code, 3 characters = ISO currency code etc.
view.FTSearch(“*” + searchValue + “*”, 0);

Document doc = view.getFirstDocument();
sb.append(“<UL>”);
boolean found = false;
while(null != doc ){
found = true;
sb.append(“<LI><TABLE class=”receivingCountry“><TR class=”level” + doc.getItemValueString(“Level”) + “”>”);
sb.append(“<TD class=”recCountryLevel“><span class=”informal”>Level: ” + doc.getItemValueString(“Level”) + “</span></TD>” );
sb.append(“<TD class=”recCountryName“>” + doc.getItemValueString(“R_CountryName”)+ “</TD>”);
sb.append(“<TD class=”recCountryDesc“><span class=”informal”>” + doc.getItemValueString(“R_CountryDesc”)+ “</span></TD>”);
sb.append(“</TR></TABLE></LI>”);

doc = view.getNextDocument(doc);
}

if( !found){
sb.append(“<LI><span class=”informal”>no result</span></LI>” );
}
sb.append(“</UL>”);
return sb.toString();

CSS applied:

.receivingCountry{
table-layout: fixed; /* in my case important to make the sugguestions fit */
width: 380px; /* in my case important to make the sugguestions fit */
border-collapse: collapse; /* needed to make the space go away */
border: 1px solid #DDDDDD;
padding: 0;
margin: 0;
white-space: normal; /* in my case very important to make the table cells wrap */
}

.tundra .dijitMenuItem {
border: 0;
margin: 0;
padding: 0; /* needed to get rid of the space between items */
background-color: transparent; /* needed to get rid of the gray oneUITheme background */
}

.level1 {
background-color: #FFCC66;
}
.level2 {
background-color: #66CCFF;
}

.recCountryName{
vertical-align: top;
width: 200px;
}

.recCountryLevel{
vertical-align: top;
width: 80px;
}

.recCountryDesc{
vertical-align: top;
width: 200px;
}

Result:

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

Posted on 2013-04-01 by admin

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)

FRULE: DominoDocument is a wild animal

Posted on 2013-03-30 by admin

Here’s the story:

We needed multiple “dynamic tables” in our projects. Thanks to Russel Maher I had something to start off with.

Too bad his solution worked on the “backend” document. After I had managed to get a “container” around his solution another problem popped up: Save conflicts.

I couldn’t figure out why this happened. I could only imagine it was some sort of “timing issue”. In his solution upon a save a cleaning of the table is done. This merely renames the fields such that they order properly (in case some rows had been deleted). In this process the document was saved in the end. Cause I had several such “tables” to handle the saves of each of those kind of interfered and created those save conflicts.

But how could I solve this?

After a LOT, you should by the time now (if you followed my blog for a while) know what a LOT means!!! Enough to almost give up! Luckily I didn’t.

I figured: if I could only “reorder/rename” those items in the DominoDocument, then those changes would “magically” be transferred to the document upon the actual save. This is all thanks to the architecture of JSF, the data store etc.. (don’t ask me details, I am just about to get a hang on this one!)

So while I tried to get this working I always came accross this thing here.

As I mentioned in that other blog: that guy reporting this error on the Lotus forum had mentioned it happened when trying to put a NULL value vector somewhere.

After a LOT of testing I found: this is exactly what happened in my case!!! I was trying to copy values from date fields over (in order to rename them). But date fields which have no date simply have a NULL in them.

So the final solution was pretty simple: Just check if that item is available or has a NULL value.

Now my solution works smooothly: no more save conflicts, just the way I imagined!

Here’s how it could look like:

FRULE: NotesException: Note delete failed

Posted on 2013-03-28 by admin

Error while saving document
Could not save the document NEW_1d NotesException: Note delete failed

NotesException: Note delete failed
    lotus.domino.local.Document.Nsave(Native Method)
    lotus.domino.local.Document.save(Unknown Source)
    lotus.domino.local.Document.save(Unknown Source)
    com.ibm.xsp.model.domino.wrapped.DominoDocument.save(DominoDocument.java:1087)
    com.ibm.xsp.model.domino.DominoDocumentData.doSaveDocument(DominoDocumentData.java:567)
    com.ibm.xsp.model.AbstractDocumentDataSource.save(AbstractDocumentDataSource.java:76)

what the heck is this???
I only found a very old note in the 6/7 LN forum. The guy thought it was related to some “null value vector”..

any ideas?

Update:
It happens when you try to put a NULL value vector somewhere, see also this blog. It’s a feature not a bug!

QUINDIP: how to debug java in xPages (reminder!)

Posted on 2013-03-26 by admin

just wanted to reiterate again to those developing in Java for xPages how easy it is to debug ALL Java code run in an xPage (yes, ALL, even the Java code which “creates” the xPage and all it’s controls!)
click here to read my earlier article

QUINDIP: computed when composed fields in xPages

Posted on 2013-03-25 by admin

Did you ever wonder how you can “mimick” the cold computed when composed fields?

According to Brad Balassaitis there ain’t no equivalent in xPages.
According to Oliver Busse you can “fake” them anyway

Steps I would propose:

create a normal editable field and set it “disabled”
use this css to remove the border of the input: input[disabled]{border: 0px;}
use Olivers approach to add a value when the doc is first opened

<xp:actionGroup>

<xp:setValue binding=”#{docCurrent.docRequestID}”

value=”#{javascript:@Unique()}”>

</xp:setValue>

<xp:setValue binding=”#{docCurrent.docCreationDate}”

value=”#{javascript:@Now()}”>

</xp:setValue>

</xp:actionGroup>

It looks like this in the binding dialog:

I tested it, I think quite thoroughly: it works. I also tried to “change” the value via Inspector in the HTML source code.. after save&reload the old value was back.. so Notes seems to “know” which fields CAN and CANNOT be edited!! This is great news!

the fields are setup on creation of the document, they are saved to the document, they look like “static text”..

YOUFEB: YOUr FEedBack required

Posted on 2013-03-25 by admin

I wanna thank to all loyal readers of my blog. I know you’re out there somewhere…

Please get in contact with me.. write comments about my blogs, what you liked, in terms of content, in terms of writing style, what you didn’t like, what you missed.

Let me know who you are and what problems your dealing with…

I know most of you (besides maybe some 20 guys around the world) are struggling with the same issues than I have…

Have you ever wondered if it is possible to keep all code within a LN application in one place? Say ONLY in the java classes?

I believe the interface with drag&drop of fields, clicking on properties, entering attribute values etc. is great, but it’s also a GREAT pain!!!

Who of you has read my post about “do not copy and paste” stuff? Where an xPage wouldn’t behave, just because I copied and pasted and forgot to remove one of those “properties”…

I do envy those guys working with GWT.. they GUIs are so slick, so fast, so adaptable… and as far as I know they application runtime lifecycles are more easy to understand.

Or can you really tell me about the order of execution of all those “events”? Or when the first moment would be where you have a handle to the DominoDocument?

I do understand that most LN applications are just “little” adaptations of document mgmt templates, discussion templates etc.. but hey.. there are people out there really trying develop high-end applications, including workflows etc…

stay tuned for more questions answered from my side.. and tell me about your questions…

Michael

QUINDIP: full source to display miniature flags in your apps

Posted on 2013-03-24 by admin

This is a real time saver for you… well.. it took me some hours to get the whole thing done and tested.. few flags might be missing in the css code and a few have not been verified, but most countries are handled.
Enjoy!
(full source code at the end of the blog)

This time we start with the result: You want to have country flags displayed somewhere, say in a type-ahead (see this post)

That’s the HTML source code:
<TABLE>
<TR>
<TD><SPAN class=”FR”></SPAN</TD>
<TD>FR</TD>
<TD>FRANCE
<SPAN>some company info</SPAN>
</TD>
</TR>
</TABLE>

Here the file with flags from most countries in the world (you can download it)

here the css styles used to display the flags:

/* switzerland */
.CH{
display: inline-block;
background-image:url(‘flags.png’);
background-position: -200px -89px;
width: 11px;
height: 11px;
}

/* germany */
.DE{
display: inline-block;
background-image:url(‘flags.png’);
background-position: -284px -117px;
width: 16px;
height: 11px;
}

/* usa */
.US{
display: inline-block;
background-image:url(‘flags.png’);
background-position: -4px -565px;
width: 16px;
height: 11px;
}

resources available here

the updated css fixes a minor bug when adjacent rows are higher than the flag and other flags would be “displayed”