I've been working on the web UI for the SmartCloud Notes administration, and we recently ran into a limitation. We have a lot of Custom Controls, and are translated into a lot of languages, so that means there are a whole lot of automatically generated .properties files that you don't see in the Domino Designer UI (unless you open the Navigator or Project Explorer view). Each of these files is considered a design element, part of the design collection of the database, and Designer (and the Notes client) unfortunately can't deal with more than about 7,000 design elements total (your mileage may vary).
So when we hit that limit, we went looking for design elements we could delete. One thing we noticed right away was that many of these .properties files didn't actually contain any messages -- Designer was creating them whether or not there were strings to localize. If we could just get rid of those, we'd be in good shape. And as it happened, we could get rid of them -- I wrote a script to do that -- but they come back every time you do a build.
Fortunately, the XPages team are available to us on SameTime, so I found a helpful fellow to add an option for us. Turn this on, and Designer will no longer create .properties files unless it has some messages to put in them. This will be available starting in release 9.0.2.
It will not get rid of superfluous .properties files that already exist -- you still need a script for that. But it will stop the creation of new ones. This has allowed us to continue developing those new SmartCloud admin features you like so much, and also adding even more languages -- Croatian and Romanian are in the queue for release in the near future.
You might never have enough design elements for this option to be useful for you. But if you do... here it is!
The print version is now live on Amazon.com, with electronic edition and other vendors to follow.
| Doctor Dead, A Percy and Quincey Adventure |
San Francisco, 1904: Thirteen-year-old Percival Drew expected to spend the summer doing little more than tinkering with those new-fangled gasoline-powered motorcars. But that was before an insane scientist took an unhealthy interest in his cousin Quincey's very rare blood type... Before people began vanishing from the streets, to reappear as the mad doctor's undead minions... Before the villains infernal devices gave him the ability to strike at will, destroying all who opposed him! With chaos descending on San Francisco, only two boys know the secret to defeating the undead doctor. But can they act in time?
We've been having a problem with one customer who was migrating their on-premises mail users into SmartCloud Notes, because they ade a mail template change in their on-premises environment after giving us "staging" replicas of some users' mail files. The DESIGN task on the users' on-premises servers updated their mail file designs from the template, and this change replicated to users' local replicas (MMRs in this case). When the users replicated their local mail files with the service, the on-premises design changes were more recent than the design on SCN, and "won" the replication conflict. This resulted in local mail replicas with a "mixed" design of design elements from two different templates.
End users don't have access to update the design of their SmartCloud mail files, but they're using their local mail files so still see the error messages resulting from this mixed design.
Our recommended measure to prevent this, is to turn off the DESIGN task on the users' mail servers (including clustered servers) and make sure you know about all server replicas.
Alternately, if customers don't want to turn off DESIGN, they can process the user mail files to prevent template updates by removing the "inherit from" template name, and scanning for design elements that inherit from a specific template. But turning off DESIGN is probably simpler and safer.
We're adding instructions to the on-boarding process to prohibit any changes to user mail files design after their replication to the staging server, and updating our training materials. We'll cover this in an upcoming partner call, but meanwhile, I thought I should mention it in case there any ongoing rollouts where it may be an issue.
I thought I should note this change, since there's nothing in the "liveAdmin" UI (as yet) to indicate how it works. That will have to wait until we can translate the explanatory text into all our supported languages. But you can use the new functionality now.
If you have a set of SmartCloud Notes users that you want to -- let's say -- assign a new mail file design using the web-based administration UI, you used to have to search for the user, select them from the search results, click the button to apply the action, specify the parameters (e.g. which mail template to use), wait for it to complete, then repeat the process with the next user.
Starting now, after you have selected a user from the search results, you can just do another search. Any user you selected, will remain displayed on the results screen, so you can accumulate a list of users through multiple searches. Then, apply the action to all of them at once, only specifying the parameters once. This is especially helpful for provisioning users, where you have to answer several questions. And of course, if you're assigning mail templates, which is slow, it's great to be able to start a batch and have your coffee break.
Please don't forget to check the box for the matching user from the final search -- only selected users will be processed.
Follow this page for a fuller description of this and other new feature announcements.
I recently started using the Domino Designer 9.0.1 client, and immediately noticed this slightly alarming warning in my XPages applications. The product help page "What's new in IBM Domino Designer 9.0.1 Social Edition?" lists several XML elements for which a "role" property is deprecated (search for "Obsoleting of the role property") but it was unclear whether it would still work anyway and how any difference in the build version versus the execution version was a factor. Role is used to tag elements for accessibility, so it's important to us in meeting our accessibility compliance targets.
So I called up the appropriate developer and quizzed him. Here's what I learned:
- The "role" property isn't completely deprecated. There are other elements not in that list, to which it still applies. You still have to specify the role for those.
- For those XPage elements, including viewPanel and pager for instance, that are on the list, the Domino server now automatically supplies a "role" value, so you need not specify a role for those elements.
- However, the property still works, letting you override the server's choice if you need to. You'll just get a warning in the Problems view.
- Since the code to determine the correct role is in the runtime, not in the "build" code, if the application is built by 9.0.1 but executed by an earlier version, the role attribute will not be included in the HTML unless you have specified it– just like now. In that situation, ignore the warning and specify the role anyway.
If you've been doing development work that involves OpenSocial and Domino, I'm interested in quizzing you a little. Please reply privately using my email, which is my first and last name, with underscore, @us.ibm.com.
At about 1:10 in this news clip: http://minnesota.cbslocal.com/2013/06/23/at-the-fix-it-clinic-learn-to-fix-your-electronics-appliances/
Fixin' stuff. As I do.
A little while ago I wrote about our process for prioritizing bugs for fixing. Mathieu Pape has a related idea recently posted on IdeaJam, that you might consider supporting if you're interested in this issue. It seems like a good notion to me.
XPages lets you write code to calculate the values for selection lists. The value your code returns may either be an array of strings, using the pipe symbol ("|") as a delimiter between display value and stored value, or it may be an array of javax.faces.model.SelectItem objects, which each contain a display and stored value as separate data items. It's your choice. The latter method, however, is more bulletproof since you don't have to worry about pipe symbols in your data.
Experienced Domino developers are used to specifying the choices for keyword lists -- comboboxes, radio buttons and the like -- using the pipe symbol ("|") as a delimiter between the value displayed and the value stored, hence: "Yes|1", "No|0".
For XPages, the Designer UI provides a separate place for entering the display value and stored value if you have a hard-coded list:
If you need to calculate the value of the selection list at runtime, using the pipe delimiter is still an option. Here, for instance, is the XSP code for two hardcoded choices and two calculated choices (or whatever number the code chooses to return). For simplicity, the calculation produces a constant value, but use your imagination.
<xp:selectItem itemLabel="Yes" itemValue="1"></xp:selectItem>
<xp:selectItem itemLabel="No" itemValue="0"></xp:selectItem>
This works. Or, you can return an array of objects:
Although it's somewhat longer, the nice thing about the latter example is that it doesn't fail if the "display value" contains a pipe symbol. This can occur in any case where you don't control the incoming data (for instance, if the choices are looked up from data in user-created documents). Or, as in my previous blog entry, the pipe symbol is used if you're using an application with localized values in it. When the .properties files are automatically generated, the to-be-translated strings in the foreign-language .properties files are prefixed with a string which includes a pipe symbol:
radioGroup1/xp\:selectItem/@itemLabel=[sq| No ]
So if your strings are somehow derived from .properties files, the application will fail to work in other than the original language until translation is complete. That is, of course, only one way that "|" can get into your data, so if you want to be safe, use the SelectItem object -- even if you have no intention of translating the application.
I may be stating the obvious, but I wasn't the only one on my team caught out by this, so I thought I'd best mention it.
I recently discovered the hard way that there's a problem with using < script > elements in XPages. Always use < xp:scriptBlock > instead. Why, you ask? Either seems to work fine!
BTW if you're thinking the translators will be smart enough to recognize source code when they see it and leave it alone, (1) not a good thing to count on, and (2) the other-language property files will mess up the functionality even before translation starts, because they tag the to-be-translated strings with, e.g. "[zh_TW" at the beginning, which won't still be executable code.