Category: xPages

bookmark_borderBIG THANK YOU to all my readers

Posted on by admin

A big “thank you” to all of you. 

You helped raise attention to my blog (as of 2013-04-03 this blog is just under the top 50 of the past 5 days in this list) and it seems some important people in the xPages community do read my blog (at least once in a while 😉 )

I can only assume that the content combined with my, hopefully funny, style to write are responsible for the hits I get.

I don’t know why, but somehow my blog seems to hit some pain points out there.

Maybe some of you might now already why I created this blog:
xPages are a great technology, BUT it’s really hard to find decent documentation.
Everything is POORLY documented and you need to collect bits and pieces all over the web to get some stuff going properly and this is frustrating and takes literally ages!

The xPages TOP CRACKS out there doing some interesting blogging: they know their stuff, too good actually. Sometimes they miss the important little things, the little things which drive us newbies crazy because we don’t get the stuff working.

Example:
The repeat control. Has anyone of you ever wondered why the “Collection name” is called collection name?
I always thought in Lotus Script terms of a collection.
It took me a while to understand that the actual “meaning” of this property was a handle to the single record/data/document within the collection! So why not call this stupid property something like “entity handle” or “entity name” or “single data entry handle”.. or something we newbies can understand well at once!

Take this example video which I think is great, but it has a minor glitch and no-one seems to care 😉
Check out min 1:13. He says: we add a collection name “rows” (plural!) and then he enters anyway “row” (singular). If you don’t pay attention you will never get it to work. I had to zoom in (ie. fullscreen until I figured out where I made the mistake!)

Don’t get me wrong:
I’m not accusing anyone of anything here! I just noticed on my learning way that I was over and over and over and over (how many times shall I repeat?) not really happy with the information I was looking for.

I just think that the beginner xPages developer needs to know also the little details. An attribute wrongly activated/selected etc.. and nothing works. And the error messages you do get, com’on.. you all know it: THEY ARE USELESS!!! It takes you again (shall I repeat?) HOURS to figure out where the actual problem is. Thankfully I did figure out how to debug Java code and this makes my life a whole lot easier.
But again: why does IBM not propagate this great feature more openly??? I would expect it even in the help of the designer!

Summary:
I think I had a great, difficult and bumpy but yet steep, learning curve in the past 6 months, way more to go I assume. But the knowledge I have now is quite sufficient to be a decent xPages developer.

What I expect from you guys out there:
Give me feedback!!!!! Write comments! Ask me questions and I will try to blog about more interesting things.

THANKS FOR YOUR ATTENTION

bookmark_borderQUINDIP: Solved! accessing fields before page is being displayed with Java!

Posted on by admin

Use the beforeRenderResponse event to modify fields before they are rendered and displayed on the browser!

Thanks to the phase listener implementation in our framework I could also solve the following issue:

Modify fields (set value, set read only, set hide) before the page is displayed in the browser, ie. it should arrive “properly” displayed (what else 😉 )

Up until now I didn’t quite now when to call my Bean to do all the stuff above. Sometimes the fields were not available in the view hierarchy yet, sometimes it was too late and the page already rendered.

If you use it this way you can apply all those changes (even for new documents!):

Result:

The “read” only fields are only read only for employees of our company, as is the GEID (which is otherwise completely hidden)


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

Posted on 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>


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

Posted on 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

bookmark_borderQUINDIP: format your custom type aheads properly

Posted on 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:


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

Posted on 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)

bookmark_borderFRULE: DominoDocument is a wild animal

Posted on 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:

bookmark_borderFRULE: NotesException: Note delete failed

Posted on 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!

bookmark_borderQUINDIP: computed when composed fields in xPages

Posted on 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”..