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

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

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)

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

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

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

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


                  bookmark_borderYOUFEB: YOUr FEedBack required

                  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

                  bookmark_borderFRULE: frustrated about stupid error messages

                  Scenario:
                  created xPage, added some fields, changed some properties, added custom control with buttons to save etc…, tried to create and save a “document” …
                  wouldn’t save…  wtf makes fun with me???

                  damn…

                  tried to find out what the problem was, got the idea to add an “display errors” control, guess what, there WAS an error!!

                  Search??? what search??? and WHERE?????

                  almost went nuts!!!

                  finally, you guess: after HOURS!!!, I had a brilliant or stupid idea: remove the form validations on “save” as the xPage wasn’t really “connected” to an existing form, and guess what!!

                  THE SEARCH ERROR MESSAGE DISAPPEARED!!!

                  Lesson learned:
                  1. xPages error messages are stupid as stupid can be
                  2. never use form validations if the xPage isn’t associated with an actual form

                  FRUstradedLearningExperience

                  I know.. usually all this wouldn’t happen when you start from scratch.. but as all lazy developers.. I sometimes “copy&paste” and this ain’t really helping sometimes!

                  bookmark_borderindip: use bean within another bean

                  I wanted to use a bean within another bean. And I wanted the most elegant way to achieve this.

                  Here’s what I got:

                  define the beans in the faces-config.xml as follows (notice the color codings, to show references!)

                    <managed-bean>
                      <managed-bean-name>childBean</managed-bean-name>
                      <managed-bean-class>com.abb.xpages.beans.ChildBean</managed-bean-class>
                      <managed-bean-scope>request</managed-bean-scope>
                    </managed-bean>
                     <managed-bean>
                      <managed-bean-name>ParentBean</managed-bean-name>
                      <managed-bean-class>com.abb.xpages.beans.ParentBean</managed-bean-class>
                      <managed-bean-scope>request</managed-bean-scope>
                           <managed-property>
                       <property-name>childBeanX</property-name>
                       <value>#{childBean}</value>
                     </managed-property>
                    </managed-bean>

                  then in your “parentBean” you “inject” the childBean as follows:

                  ChildBean childBean = null;
                  public void setChildBeanX(ChildBean bean){
                  childBean = bean;
                  }
                  then you can access the childBean in other places in your parentBean, 

                  Example method from the parentBean:
                  public String getColor(){
                  return childBean.getColor();
                  }

                  As always I hope someone might find this useful when struggling around with beans! Also check out my other recent post regarding scope setting if you require notes objects being serialized.