There have been a couple of challenges around this.

First, I’m aggregating error objects into a LinkedHashSet so there are no exact duplicates – because dynamically computed properties can be calculated during a number of phases of the XPages lifecycle, the same error could be encountered a number of times during a partial refresh. The errors are then logged out to OpenLog by a PhaseListener in the afterPhase() method for the Render Response phase. That’s right at the end of the lifecycle, when we cannot encounter any further errors.

However, if you call FacesContext.getCurrentInstance().addMessage()during that method, rendering has already occurred, so although they’re added to the FacesContext, all Error controls have already been rendered without any errors. So we need to add it earlier.

So I moved my code to the beforePhase() method. But that runs before the Render Response phase, so any errors encountered during the Render Response phase are not written to the FacesContext.

So I leave the writing to OpenLog until the PhaseListener’s afterPhase() method for the Render Response phase. But I moved the code to call FacesContext.getCurrentInstance().addMessage() to run the first time an error gets added to the LinkedHashSet. But I want to tell the user which component the error is for, so I include component.getId().

Here things got strange. When FacesContext.getCurrentInstance().addMessage() ran, the component had no id. component.getId() returned null. But OpenLog had the component id. The property that triggered the error was a computed on page load validateRequired validator. The source pane code is below:

Nothing unusual, so it would appear. So I looked at the .java file that gets created. You can probably see why it’s not outputting an id for the component when it hits an error with the validateRequired:

As you can see, the setId method comes after the evaluator.evaluateAsString() call which throws the error. I wondered if perhaps I had added the id to the component on a subsequent save, so perhaps the order in which the properties had been defined caused the problem. No. Invariably, setId() is called last. setUrl method on an Image control is added after setId, but that’s the only one I’ve seen so far.

So almost any loaded property is calculated before an id is added to the control.

I have an idea or two how to work around it, but it’s an interesting point to note.

For those wanting to hit the ground running with the project, I’ve posted a video on what needs deploying to the server and your client, embedded below.

Declan has also updated the JavaDoc and is kindly hosting it.

For anyone who wants a bit more information on how to use the code and some comparisons, I’ve been working on a sample application. It requires M2 as a minimum. So far there is import code and some samples of some new methods in DateTime. There is also some code to performance benchmark. I would recommend downloading from GitHub (using Git rather than Mercurial) because I will be continuing to work on it. But if you’re not comfortable yet with source control, I’m attaching a copy of the database.

OpenNTF Domino Demo Database

M1 provided the core set of Java code that offered a host of possibilities for looping Collections, avoiding recycle, throwing generic exceptions instead of NotesExceptions and providing the MIMEBean. The jar could also be added to jvm/lib/ext for use in Java agents etc and could be added to WebContent\WEB-INF\lib for use in Java in XPages. These steps alone significantly sped up development. But for M2 we’ve gone further.

Bug Fixes

We may be good but we’re still human! Some deep bugs on recycling and MIMEBean have been identified and fixed as members of the team have been using the API more intensively. Resurrection of recycled objects is robust across the run context – XPages, agents etc. Code has been added to identify the run context.

Making Integration into XPages Easier

A plugin project – org.openntf.domino.xsp – has been added to enable the jar to any XPages application on the server as well as adding global objects as entry points (opensession and opendatabase). It still requires the plugin and jar, but details of exporting and deploying from the source code are on the wiki.

If you’re working on a clean environment and want to only use the new API, you can set org.openntf.domino.xsp=godmode in the server’s xsp.properties file so we override session and database.

And the API is now fully integrated into SSJS as well. You’ll need to import the update site into Designer and put the plugin in your <notes>/jvm/lib.ext folder. But then, cast variables to the new classes (e.g. var myView:org.openntf.domino.View = …) and you will get typeahead support for standard and new methods.

Architecture of Class Interfaces and Implementations

This isn’t something you have to worry about, but an interesting change for the geeks. As part of M2 we’ve changed the underlying architecture of the API. Previously we had interfaces in the org.openntf.domino package that mixed both standard and new methods. We’ve changed that so the org.openntf.domino package has the standard methods and all new methods are in parallel interfaces in org.openntf.domino.ext. The classes that implement those interfaces are still in the org.openntf.domino.impl package. (You cast to and import the org.openntf.domino classes, but you’re actually using org.openntf.domino.impl classes, the same as happens when you cast to lotus.domino interfaces but actually use lotus.domino.local classes.)

Logging

A logger was added to M1 but wasn’t fully operational. Now it is. It allows high-level logging to server console, full stack trace logging to a file in IBM_TECHNICAL_SUPPORT folder and the whole lot also logged to OpenLog.nsf on the relevant server, if it exists. Longer term I’ll be looking at making the path configurable and other elements, which may or may not be feasible (and may even already be possible!).

Transaction Logging

You may have seen Nathan’s post last month about him adding transaction logging into the API. This is a huge addition. Most databases have code somewhere where the user clicks a button and business processing kicks off that does something like setting fields on the source document, then updating child documents or related documents in another database. What happens if the code fails on updating all those other documents after successfully updating the source document? You might have coded an exception for that but you the only possible cause may be a connectivity blip, so you didn’t bother coding for an extremely rare occurrence. But it hits exactly when you’re at your busiest!

This is where transaction logging comes in. Now start the transaction, change your fields, update your related documents and then call transaction.commit(). In your error handling call transaction.rollback(). And even better, the transaction logging that Nathan has written is clever enough to only save documents that have changed. I know I’ll be using that.

Graph Databases

Graph databases are something I haven’t yet fully got my head around. But Nathan has added an implementation for writing to Graph databases from the API.

Demo Database

We’re also working on a demo database. I posted a YouTube video (embedded below) a few weeks ago. (As an aside, what I mention as a bug in the API was actually developer error – I called the wrong method from SSJS!) The version that will ship with M2 will probably just include the data import routine and comparison of code and some of the new DateTime methods, as well as a performance comparator on looping through documents and setting a DateTime field. We’ll be adding to it to provide SSJS and Java bean samples of the full API along with code comparisons of Java to lotus.domino Java code, and also give sample Java agents.

Resting on Our Laurels?

No way. When you see the release notes for M2 you’ll see there are additional bits that are not yet operational. And I will be hugely surprised if that’s the end of the new functionality.

The overarching benefit to deploying Social Business solutions in customer service operations is the ability to engage with customers and understand them more deeply. This helps organisations to anticipate and meet their customers’ needs in ways that differentiate them from the competition.

If companies could increase customer retention rates by 5%, they could grow their profits by 25% -100%.

Frederick Reichheld, The Loyalty Effect

According to a recent ITSV CEO study, ‘Getting closer to the customer is the top focus for CEOs over the next 5 years.’

Specifically, customer service teams can:

• Find the right people via profiles connecting customers with similar interests or find employees with specific skills
• Easily adapt web content that captures customer interest based on behaviour – without calling IT support
• Streamline operational efficiencies with consistent workflow processes via enhanced email and messaging capabilities integrated with social applications
• Update web content based on customer behaviour to provide critical information when needed
• Share best practices with blogging, shared bookmarks, shared files and activities
• Provide additional online self-services for communities
• Instantly chat to experts in customer behaviour.

This article was taken from Intec’s whitepaper – Social Business – Connect. Collaborate. Compete.

For more information or to talk to Intec about Social Business Collaboration Software visit www.intec.co.uk/software-solutions/collaboration-solutions/

Or call +44(0)1252 775400

Social technologies are being used to gather insights about products and brands, opinions about competitors, and perceptions of market segments. This market research and customer insight can be used as input for product requirements and design, advertising campaigns, pricing, packaging, and other marketing and product development activities.

In a recent study of 541 executives at 500 companies, 40% found that they could see specific improvements and increases in sales from social customer relationship management and 71% found that it led to a reduction in time to resolution for support issues.

Social Businesses increase their customer reach by accessing more customers – and spending more time with them.

Social selling allows organisations to:
• Access core opportunity, contact and account data from mobile devices
• See a 360 degree view of the customer
• Reduce time spent learning about the customer
• Reduce time spent searching for experts and information
• Reduce time spent filling in opportunity data for forecasts
• Engage customers remotely with a rich set of collaboration and social tools
• Save time and cover all stakeholders with one-to-many communications
• Keep entire teams, including channel partners, in sync on closing the deal.

Social Businesses engage the entire sales team and apply expertise from across the organisation. Sales representatives can work together in collaborative communities to solve problems and:
• Gain easy access to experts for fast answers to customer questions
• Provide recommended sales content based on the specific opportunity
• Easily collaborate with co-workers from across the organisation
• Quickly reach out to experts when emergencies arise
• Re-use best practices from other teams.

This article was taken from Intec’s whitepaper – Social Business – Connect.Collaborate.Compete.

For more information or to talk to Intec about Social Business Collaboration Software visit www.intec.co.uk/software-solutions/collaboration-solutions/

or call +44(0)1252 775400

Now we’re ready to start on the two pivotal methods that do the work – readEntries() and loadEntries().

readEntries takes an IPickerOptions object as its parameter. These are the options passed in via the underlying AJAX call to the dataProvider. There are four properties used:

• startKey: a full or partial value that is passed from the Value Picker’s search box, if search is enabled by setting dojoType=”extlib.dijit.PickerListSearch” on the Value Picker.
• key: a full or partial value that is passed from an Edit Box that uses typeahead, where the typeahead is bound to the Value Picker.
• start: the starting position in the collection. It doesn’t look like there’s any current functionality in the Value Picker to take advantage of this.
• count: the number of entries to return. It looks like the Value Picker doesn’t support this property, but the Name Picker does by providing the maxRowCount dojoAttribute in the PickerName JavaScript Library, as Sean Cull blogged.

Looking at the functionality provided, it should be possible to extend the Value Picker or Name Picker to add paging which would pass back start and count options via an AJAX request. Those who saw my session at IBM Connect or the video on YouTube of the final demo from it will know that I’ve had some experience doing that. Though that’s beyond the scope of this tutorial.

So the code for the readEntries method is:

public IPickerResult readEntries(IPickerOptions options) {
String startKey = options.getStartKey();
String key = options.getKey();
int start = options.getStart();
int count = options.getCount();
int searchIndex = 0;
List opts = filteredOptions(key, startKey, start, searchIndex);
List entries = new ArrayList();
for (String opt : opts) {
entries.add(new SimplePickerResult.Entry(opt, opt));
}
return new SimplePickerResult(entries, -1);
}

So first we extract the options passed in. We then call a method filteredOptions(), passing in the various criteria to return a list of just the options we want to display. I’ll come back to that shortly, but initially it will be the same as the options_ variable we initialised the ListPicker with. We then crerate a new ArrayList, loop through the filtered options and create a SimplePickerResult.Entry object for each. Entry is a class within the SimplePickerResult class, and the constructor takes two parameters – a label and a value. For these collections the value and the label are the same, so both parameters are the same. Finally we return a new SimplePickerResult object that holds the values. In the examples I found in the Extension Library the second parameter is always -1, so that’s what is passed in here.

So now to the filteredOptions method. This just takes the options_ variable and filters it depending on those IPickerOptions that were passed in:

private List filteredOptions(String key, String startKey, int start, int searchIndex) {
List retVal = new ArrayList();
int first = -1;
if (StringUtil.isNotEmpty(key)) {
// We've got a typeahead key passed in, jump to first entry beginning with that key
for (int i = 0; i < options_.size(); i++) {
if (StringUtil.startsWithIgnoreCase(options_.get(i), key)) {
first = i;
break;
}
}
if (first >= 0) {
// And add entries that start with the key
for (int i = first; i < options_.size(); i++) {
if (StringUtil.startsWithIgnoreCase(options_.get(i), key)) {
retVal.add(options_.get(i));
}
}
}
} else if (StringUtil.isNotEmpty(startKey)) {
// We've got a search key passed in, jump to that entry
for (int i = 0; i < options_.size(); i++) {
if (options_.get(i).compareToIgnoreCase(startKey) >= 0) {
first = i;
break;
}
}
if (first >= 0) {
// And add all remaining entries
for (int i = first; i < options_.size(); i++) {
retVal.add(options_.get(i));
}
}
} else {
retVal.addAll(options_);
}
return retVal;
}

First we create a return variable retVal, an ArrayList to put our filtered options into. Then we have three checks: if key is not empty, is startKey is not empty, or if they’re both empty. The last option is what’s going to be true the first time the user clicks on the Value Picker icon – they haven’t initiated typeahead (key) or done a search in the Value Picker (startKey). In that case (right near the bottom) we just add all to our return variable.

The first if statement runs if key is not empty, so the user is typing into an Edit Box and triggering typeahead. In this case we only want to return any entries that match exactly the letters typed in. If the letters are found, we set first to that entry’s index. If first is greater than or equal to zero (it’s been initialised to -1), we then add that and any subsequent entries starting with the letters typed in by the user.

The second if statement run if startKey is not empty, so the user is entering a search into the Value Picker dialog itself. First it compares lexicographically each option to the startKey, that means that in a dictionary and ignoring case sensitivity, does it come before (less than zero), at the same place (zero) or after (greater than zero). So we set first to the entry that matches the search criteria, begins with the letters typed, or is the closest after the letters typed. We then get all subsequent entries.

Let me just give an example for the startKey scenario. Say we have a List with entries “apple”, “banana”, “grape” and “plum”. When the Value Picker is first shown, the user sees all four. If the user types “grape” or “GRAPE” or “Grape” in the search box and searches, they get a list comprising “grape” and “plum”. If the user types “ba” and searches, they get “banana”, “grape” and “plum” because banana comes after ba in a dictionary. The fact that banana starts with the letters the user is searching on is irrelevant. Equally if they type “nectarine” and search, they get “plum”, because nectarine is not in the list and plum is the next entry alphabetically that is in the list.

So the readEntries() method gets entries for the user to select from. Now onto the loadEntries() method. This is used when the Value Picker dialog is launched to identify which options in the dialog have already been selected. That’s so they can be highlighted. Here is the code we use:

public List loadEntries(Object[] values, String[] attributes) {
List entries = new ArrayList();
if (null != values) {
for (int i = 0; i < values.length; i++) {
String checkStr = values[i].toString();
if (StringUtil.isNotEmpty(checkStr)) {
for (String option : options_) {
if (checkStr.equals(option)) {
break;
}
}
entries.add(new SimplePickerResult.Entry(checkStr, checkStr));
}
}
}
return entries;
}

This takes two parameters, an array of objects called values and a String array attributes. Attributes is not used in the examples I’ve seen and not used here. The array of objects is the one or more elements from the list that were previously selected. If it’s null, we don’t have to do anything, because nothing has ever been selected before. Otherwise, for each entry in the values array we get it as a String, then loop through the options_ List and try to find each previously selected value. If we can, we add it to the entries ArrayList as a new SimplePickerResult.Entry. As before, the label and value are the same, so both parameters for the SimplePickerResult.Entry are the same.

Put this all together and we have a generic class that can be used as a dataProvider for any List or Set for a Value Picker on any page of the database. But how do we call it. First we need the List or Set. That could be provided in a number of ways. Explicitly in the code for the dataProvider; in a viewScope variable; in a dataContext; or in an xe:objectData datasource. We then just need to compute the dataProvider property of the Value Picker, creating a new ListPicker object and passing in the List or Set using the variable name from the viewScope variable, dataContext or datasource, like so:

${javascript:new org.openntf.pickerdata.ListPicker(myValuesSet)}

Now we have a fully working dataProvider. You can find the full code on XSnippets.

A dataProvider for a Value Picker needs to implement the Java class com.ibm.xsp.extlib.component.picker.data.IValuePickerData (implement not extend). I also needed to implement Serializable, just like we do with a bean. IValuePickerData is an Extension Library class, so the source code is freely available on the OpenNTF project and you can look at it in Eclipse. When you import the Extension Library source code into Eclipse there are quite a few Eclipse plug-in projects involved, so the plug-in project you want to look at is com.ibm.xsp.extlib.controls. Expand the src folder and look in the package com.ibm.xsp.extlib.component.picker.data.

First off, you’ll see IPickerData is not a Java class but a Java interface. If you’re relatively new to Java, you may not know the difference. An interface defines a set of properties and methods that any Java class based on this interface must implement. It specifies the property data types and method names, parameters and return types. But there is no code in the methods in the interface. It’s effectively a schema that says “You must include these methods and I don’t care your code actually does, as long as it takes these parameters and returns this type of object”. The Extension Library does provide example implementations of the IValuePickerData interface, including both the SimpleValuePickerData and the BeanValuePickerData. And there is also the example in the Extension Library Demo database.

There are four methods that have to be implemented:

getSourceLabels() takes no parameters and returns a String array. This is used by the Name Picker to define labels for each dataProvider, because the NamePickerAggregatorData allows you to add multiple dataProviders, for which you need to give a label so the user knows which is which. The Value Picker only allows one dataProvider, so we can just return null, like the two examples available.

hasCapability() takes an int parameter and returns a boolean. SimpleValuePickerData returns false in all cases whereas BeanValuePickerData calls a hasCapability(int) method of the underlying bean. Looking at the interface, it appears this is used to check what functionality can be applied to the Value Picker – label, search by key, extra attributes, search list, multiple sources, multiple aggregation. The DominoViewValuePickerData class (extended eventually from AbstractDominoViewValuePickerData class) provides all except multiple aggregation. The NamePickerAggregatorData class provides only multiple sources.

readEntries() takes an IPickerOptions object and returns an IPickerResult object. This is used to retrieve the values the user can select from. This is the first method we’ll implement.

loadEntries() takes two parameters, an array of Objects and an array of Strings. It returns a List of IPickerEntry objects. This appears to be used to validate the component the Value Picker is bound to, if validation is done, or to highlight the already selected entry / entries when the Value Picker dialog is presented to the user. This is the other method we’ll implement.

In the example of the BeanValuePicker in the Extension Library demo database, the readEntries() and loadEntries() methods both explicitly go to the States properties file and load the contents. But the aim here is to make it generic, to be able to specify the contents and load them accordingly to return the right kinds of objects.

So the first step is to add a new property, then create not only the default constructor for the class, but also two more as below:

private List options_ = null;

public ListPicker(Set options) {
options_ = new ArrayList(options);
}


So we have two additional constructors. The first takes a List and the second a Set. That’s because they are different underlying Java classes, so we can’t just pass in our TreeSet to the ListPicker(List) constructor. Nor can we pass in the ArrayList to the ListPicker(Set) constructor. But the ListPicker(Set) constructor converts the Set to an ArrayList, so we have a consistent approach.

Next we’ll go on to creating the readEntries() and loadEntries() methods and bind the ListPicker to our XPage.

The Value Picker, like the Name Picker, does not take a selectItems component as its source but rather a dataProvider. Why take a different approach? The selectItems component doesn’t permit any searching or “starts with” functionality, which is included in dataProviders. There are three dataProviders available  to choose from for a Value Picker:

• dominoViewValuePicker, allowing the developer to map to a Domino view.
• simpleValuePicker, taking a String of options. Properties allow the developer to define whether searching is case insensitive, what the separator between labels and their respective values is, and what the separator between each value is.
• beanValuePicker, where you can create a Java bean where you code methods to retrieve the values and handle searching.

Sometimes you don’t want to or can’t create a specific view from which to get the options. You won’t be able to create a view if you’re picking options from a keyword document. If, for example, you have country documents with a geographic region defined and you want to restrict to a previously-selected geographic region, you won’t want to create a separate view for each geographic region and you can’t pre-select all entries based on a key.

None of these dataProviders takes a Java collection as its source, so we have to get a little more sophisticated. The option with the lowest level of complexity would appear to be the simpleValuePicker. But although this is the easiest, it’s not going to perform very well, because you need to take your ArrayList or TreeSet or other collection and convert it to a String. And what if you’re working dynamically from documents under a specific category and a lot of documents get added? What are the limits, and how do you work around them? Plus (ideally) you’re wanting to constantly build your expertise, so you want to look at the beanValuePicker.

First off, the beanValuePicker is not the easiest of beasts to understand. Also, the examples in the Extension Library demo database are rather hard-coded. The beanValuePicker there works only with states. There’s nothing that gets passed in to determine the source. There are no properties you can set to make it more generic. But if you want to pick from keywords documents, for example, that’s exactly what you want: something generic that you can pass a key to and get the options for.

Thankfully, Toby Samples pointed me in the right direction by saying the dataProvider can be computed – just like virtually everything else in XPages. So in the next article I’ll explain the key methods of a dataProvider and how to extend it to make it more flexible by passing in a collection.

Well you could run an @Unique and a JavaScript sort once you’ve retrieved it. But part of the point of using Java is better performance, easier debugging and avoiding coding directly on your XPages. Remember that our getKeyEnts() method got values from a keyword. Consider if we’re using the same kind of code multiple places in our application and we refactory the getKeyEnts() method to call a static getKeyVals(String) method in a utilities Java class. We’d need to code our @Unique and JavaScript sort every single time, rather than putting it in that one static method.

(Just to deconstruct that for newer Java developers, this means a getKeyVals method that takes a String parameter and is stored in a utilities class. By making the method static, we can call it by just using myClass.getKeyVals(keyStr) instead of creating an instance of myClass first.Utilities classes tend to contain static methods.)

So we need to look for an equivalent to @Unique and sort in Java, don’t we. No, we don’t. Because I started the introduction by mentioning that cheat sheet of Java Collections. I’ve put the link here again in case you didn’t download it yet. Go and do it. Note the columns Ordering and Allow Duplicates. And notice the row for TreeSet, especially the notes:

A very nice alternative for ArrayList if
**Do not want repetitions
** Sorted order

A Set, like a List, contains only values, no keys. So yes, this gives us exactly what we want, out of the box.

Almost.

Because you can’t put a TreeSet directly into a selectItems control. So we need to convert the TreeSet to something that can be put it in the control. And this is also where I come back to the mental block I was having that there is no Java class called java.util.Array. Time for more code:

public String[] getKeyObj() {
Database currDb = ExtLibUtil.getCurrentDatabase();
View vwUser = currDb.getView("Keywords");
ViewEntry ent = vwUser.getEntryByKey("ACQUIRED SKILLS", true);
Vector<String> users = (Vector<String>) ent.getColumnValues().get(1);
TreeSet<String> test = new TreeSet(users);
String[] retVal = new String[test.size()];
retVal = test.toArray();
return retVal;
}

There is no Java class called java.util.Array because String[] is the notation for a String array. We create a new TreeSet passing the Vector into the constructor – the same syntax would be used for an ArrayList and we would use new ArrayList() to initialise it blank. The good news is that by passing the Vector into the TreeSet it automatically de-dupes and sorts. We then create a new String array sized to the number of entries in the TreeSet. Finally we pass into the array test.toArray(). Simple and extremely powerful.

This handles all the core controls. But what if we want to use a ValuePicker. That’s a bit more complicated, but I’ll leave that for next time.

There are two types of Collections you may have – Lists and Maps. Lists just have values. Maps have keys and values. So if you want the label and the value to be the same, use a List. If you want a different label and value, use a Map, with label in the key and value in the values.

I’m going to start simple with Lists and start at the basic level with core controls. This is also relevant to the Dojo controls like Dojo Filtering Select, Dojo Radio Button. That’s because all these controls take an xp:selectItems complex type as its value. If you’re like me, the most common use case is retrieving values from a field in a keyword document, either from the document itself or from column values – the equivalent of an @DbLookup(). The other most likely use case will be iterating through categories in  a view and outputting category titles – the equivalent of an @DbColumn().

As you’re probably aware, the output of both of the SSJS ways of doing this is an Array. The obvious route I took was looking for a Java class for that. But there is no java.util.Array and this threw me for quite a while when trying to reproduce one-to-one. The good news is you can just pass in an ArrayList<String> or a Vector<String>. For those just starting out on Java, this means an ArrayList or Vector which contains String values. Vector is the stock collection output of Domino objects, whereas ArrayList is the standard basic Java collection object that replaced Vector. You can even use Vector<Object>, although I suspect it will only work if each value is actually a String.

So time for some code:

public Vector<Object> getKeyEnts() {
Database currDb = ExtLibUtil.getCurrentDatabase();
View vwUser = currDb.getView("Keywords");
ViewEntry ent = vwUser.getEntryByKey("ACQUIRED SKILLS", true);
Vector<Object> users = (Vector<Object>) ent.getColumnValues().get(1);
return users;
}

So we’re going to the Keywords view in the current database, getting the entry with the key “ACQUIRED SKILLS” and returning column 2 (remember the index starts at 0). Then in the XPage, we call it like so:

<xp:comboBox id="comboBox1">
<xp:selectItems>
<xp:this.value><![CDATA[${javascript:pageController.getKeyEnts()}]]></xp:this.value>
</xp:selectItems>
</xp:comboBox>

So I’m calling via SSJS the getKeyEnts() method I showed above, which is in my pageController bean. I could streamline the code even further by use ${pagerController.keyEnts} to call the method. The clever bit here is that there is no keyEnts property in my bean. Because value is a property of selectItems, it expects a valueBinding – that is a binding to a Java property rather than a methodBinding which is a binding from an event to a Java method. The valueBinding automatically looks for a method starting get and appending the property, replacing the lower-case first letter with an upper-case. So the getter for keyEnts property will be get + KeyEnts = getKeyEnts().

So Vectors and ArrayLists can automatically be thrown at any selectItems control, whether for a Combo Box, a Radio Button or even a Dojo FilteringSelect. They will give you a list of options in the order the list was populated, where the label and the value are the same.

Those Collections are very useful for managing content, but sometimes it’s not obvious how to provision those Collections for selection components such as Combo Box, Radio Button, Value Picker etc. In this series I plan on covering those, some of which are easier than others, and include a set of PickerData classes that can be used once in an app, dynamically mapping to a collection you pass in.

Business Use Cases – Product Development

By removing barriers between people, a successful Social Business can quickly and cost-effectively bring new solutions to market and better meet customer needs.

By using social platforms for co-creation, Social Businesses can engage a larger community beyond their own R&D staff. This helps to resolve product development challenges that are too big for in-house resources to handle themselves. In ‘crowd-sourcing’ for example, a wide range of participants are asked to submit ideas, which are then evaluated, often by the crowd itself.

Social Business can help organisations to increase revenue by responding to markets faster and with more innovations. It provides an effective means to create and engage distributed product teams in an easily manageable way. These communities can work via a common dashboard with complete visibility across project details and people skills. This increased visibility across multiple work-streams eliminates silos, reduces project overlaps (which waste resources) and enables re-use of improved practices across communities.

Being a Social Business will also bring increased process innovation. For example CEMEX, a global cement supplier, created a social network to accelerate new product development through open collaboration among 20,000 employees. This resulted in a new global brand of cement mix being delivered in less than 4 months, compared to 12.

This article was taken from Intec’s whitepaper – Social Business – Connect.Collaborate.Compete.

For more information or to talk to Intec about Social Business Collaboration Software visit http://www.intec.co.uk/software-solutions/collaboration-solutions/ or call +44(0)1252 775400

Since the release one of the significant enhancements is transactional processing by Nathan T Freeman. We’re also now a step forward in providing access from SSJS to all the new methods, though there is still quite a bit of work to do on that. Part of that work has also proven the method for accessing the code from XPages. As a result, work has begun on a demo database. With the help of various developers in our chat and some open source Java projects (one of the benefits of XPages being closely coupled to Java), I’ve included a couple of nice features:

• To display on an XPage a method’s code from a text-file copy of the relevant classes.
• To compare the code using lotus.domino packages and org.openntf.domino packages, showing what code is no longer required and added.

I’ve recorded a preview of the demo database. The aim is that, with the JavaDoc, this will highlight new or changed functionality, how to implement it, and why to use org.openntf.domino.

And you’ll want to, because they are very useful if you use a lot of SSJS. Some of them fall into distinct groups.

The first I’ll cover are @Functions for posting to xp:message (Display Error) and xp:messages (Display Errors) controls. They are @InfoMessage, @WarningMessage and @ErrorMessage. They each add messages for the user, great for error or other message handling. For those starting out on using Java, they’re also very useful to review because you can download the Extension Library and see what is happening under the hood. As with the others, they’re in the NotesFunctionsEx class of the com.ibm.xsp.extlib.javascript package of the com.ibm.xsp.extlib.domino plugin project. They each call FacesContext.addMessage(), each adding a message with a different severity – SEVERITY_INFO, SEVERITY_WARN and SEVERITY_ERROR.

The second group of @Functions are for URL handling – @AbsoluteUrl, @EncodeUrl, @FullUrl and @IsAbsoluteUrl. @FullUrl provides the URL for the resource relative to the server, @AbsoluteUrl includes the server host name and protocol. For those getting started with XPages, @AbsoluteUrl, @EncodeUrl and @FullUrl call static methods in the NotesFunctionsEx method that can be called from Java – absoluteUrl(String), encodeUrl(String) and fullUrl(String). So you can call them from Java as well. The last one already exists in Java – com.ibm.xsp.util.FacesUtil.isAbsoluteUrl(String).

The remaining new @Functions are @NormalizeSubject, @TopParentID, @TopParentUNID and @ViewIconUrl. @NormalizeSubject is useful to return “Untitled” if the text passed in is blank or restrict it to a number of characters, by default 80. Again, there’s a Java method in the same class, normalizeSubject(String subject, int maxlength). @ViewIconUrl is useful for taking a view icon number and returning the URL for the relevant icon. That doesn’t have a specific static method, but there’s nothing stopping you using the code, if you want to use native Java.

The other point of this is to highlight the amount of code required to provide SSJS @Functions. For those 11 @Functions, the Java class is 599 lines long. We’re looking to provide the same functionality for the new methods in org.openntf.domino, and we currently have about 50 new methods. Needless to say, it takes quite a bit of work to extend them to SSJS. We’ve already added them for the DateTime class, but there are a number of others yet to do. But we want to get there.

So in the meantime enjoy the @Functions provided now out-of-the-box in Notes and Domino 9.

Social Business provides a gateway for current and relevant information exchanges across geographies and organizational silos. Building trust and encouraging social interactions is key to driving social change in the workforce.

A successful Social Business will not foster an environment whereby employees are constantly chatting to their Facebook friends.

It is not about wasting time but about saving time and increasing efficiency, although trust is a key element for success. An organisation needs a certain level of trust to empower its employees to share their ideas and expertise, and it must demonstrate this trust by rewarding the behaviour.

This article was taken from Intec’s whitepaper – Social Business – Connect.Collaborate.Compete.

For more information or to talk to Intec about Social Business Collaboration Software visit www.intec.co.uk/software-solutions/collaboration-solutions/

or call +44(0)1252 775400