wissel.net

Category XPages
I recommended the use of IBM OneUI before including a helper stylesheet. While there is a complete documentation available, a little explanation about the how and why goes a long way. The OneUI is not so much about colours and fonts, but about structure, navigation and layout. Following its guidelines your applications get a consistent look, which user studies show increase user confidence about their ability to use your web application. This translates into less help desk calls. Any consistent framework does that, the advantage of the OneUI is that your applications start looking consistent to the IBM software in use. Furthermore when IBM releases a new visual style, your application can adopt it in no time. Lets have a look at the layout of a OneUI page. It consists of the following structure:

• Global Navigation: Branding (corporate and application logo), links to core applications, usern ame, login and help
• Application Navigation: Typically a tab bar on the left and the search box on the right. Search, while potentially acting on the current page content is considered an application level function. You could use a dropdown to allow the user to define the search context
• Place / Page Navigation: Contains the page title on the left and a series of page level actions on the right. A page would be the place where you conclude an entire interaction. This is different from the Notes client or classic web application model where view (selection of information to act on) and document (the instance of information) are usually on different pages. Some rethinking required (Partial page refresh is your friend!)
• Main Content: The main content area has one to three columns where the left and right column are optional. If the main content needs navigation or filtering that would be displayed in the left column with navigation above filters. In the right column contextual information can be displayed (e.g. in a Claim form the right column would show the account summary)
• Footer: The footer area contains logo, copyright and related links that are not frequently uses (e.g. Feedback, documentation, other software)

Drawn on a wire frame you get this:

An empty page just containing the layout would look like this:

This is also available in blue, red, gold, metal, black and white and it even is usable using Lynx. Branding fanatics will highlight that the logo area is tiny and the footer to long, however nobody stops you from altering the CSS, as long as you stick to the structure (the small logo saves valuable space above the fold). Some Lynx impressions:

Posted by Stephan H Wissel At 8:03 PM Location Singapore | Permalink | Comments (4) |      

Category XPages
Brian shared his implementation of multi-column check boxes. Having such a control mimicking the functionality of the Notes client is pretty helpful. Brian's approach however wasn't very re-usable, so I though of a way to come up with a more reusable solution:

The resulting custom controls can be easily added to any page with a few lines of code. You need to reference 2 supporting JavaScript libraries and then add a few lines to your page: You have 4 parameters:

• numberOfColumns: (Integer) number of columns to use
• dataBindingName : (String) field to bind the control to including the datasource
• FieldValues: (Array of Strings) Values to offer in the control
• disabledValues: (Array of Strings - optional) Values that are disabled

The same parameters also work for a group of radio buttons: The controls are available for download on OpenNTF (of course you use Guo Yi's Import and Export for Designer for this). Enjoy and share your ideas for v1.1
As usual YMMV.

Posted by Stephan H Wissel At 1:24 PM Location Singapore | Permalink | Comments (6) |      

Category XPages
Look at the source code of any XPage in your browser (you are are using Firebug, are you?*) and you will find numerous invocations to the XSP object. This object sits on top of Dojo (at least for now) and is one of the reasons why type-ahead and partial refresh work so easily in XPages. Having a closer look at the object reveals a wealth of possibilities. A good starting point is an article by Teresa Monahan (one of our code goddesses in the IBM Dublin Software lab) on the Domino Designer WIKI. To get a deeper look simply examine the source. You can find the file in [Your Notes/Domino data directory]/domino/js/[DojoVersion]/ibm/xsp/widget/layout/XSPClientDojo.js.uncompressed.js. Let us have a look at some of the interesting functions and possibilities. XSP has a strong heritage in Dojo, but IBM might provide alternate implementations for specific needs in future. To get a head start in Dojo check out Mastering Dojo, Dojo: The Definitive Guide, Practical Dojo Projects or the other Dojo books. But back to XSP:

• XSP.addOnLoad( listener )
  Adds a function "listener" to the code that is executed when loading a page.
• XSP.attachClientScript(targetClientId, _event, clientScript), xsp.attachClientFunction(targetClientId, _event, clientSideScriptName)
  Attaches a function to a client element for a specific event. If the function exists use attachClientFunction. If the code is inside the variable "clientScript" use attachClientScript
• XSP.setSubmitValue(value)
  Overwrites what a submission is sending back to the server. Use with caution!
• XSP.canSubmit()
  Returns true/false. If a page has been recently submitted it returns false. Good way to prevent submit button double click hazards. To manually set it to true call XSP.allowSubmit()
• XSP.addPreSubmitListener(formid, listener, clientId, scriptid)
  Adds a function (the listener) that runs before the form (formid) is submitted. Great way to run cleanup code in custom controls to make them self contained. Also a good way to have code run only for a specific button (clientid) rather than onsubmit in any case. The scriptid helps to check if the listener has been loaded already (e.g. on partial page refresh) to avoid duplicate loads. If listener returns false submission does not happen. Runs after the client side validators.
• XSP.addQuerySubmitListener(formId, listener, clientId, scriptId)
  Same as above but runs before the validators
• XSP.alert(message), XSP.error(message), XSP.confirm(question)
  Currently this are wrappers around alert() and dojo.confirm(). Using this functions has the advantage of instant beautifications once the XSP object gets upgraded
• XSP.attachValidator(clientId, validator, converter)
  Allows to attach a validator to a client object. The better way to validate than writing code in the onSubmit event. Admittingly a little more complex. The function warrants its own blog entry (stay tuned)
• XSP.validateAllFields(true|false)
  Default for this is false. When set to true all client side validation is executed not only all until the first error. You will get a number of prompts. Makes sense with an overwritten validation function, but that's a story for another time.
• XSP.attachEvent(clientId, targetClientId, _event, clientSideScriptName, submit, valmode, execId)
  Attaches events to client side elements. The clientId is the element, the targetClientId the target for a partial refresh, _event the event to attach. More in a future blog entry.
• XSP.fireEvent(evt, clientId, targetId, clientSideScriptName, submit, valmode, execId)
  Allows to trigger an event script.
• XSP.attachPartial(clientId, targetId, execId, eventName, scriptName, valmode, refreshId, onStart, onComplete, onError)
  Attaches events to client side elements. The clientId is the element, the targetId the target for a partial refresh, eventName the event to attach. on(Start|Complete|Error) the functions to run locally around the ajax event. More in a future blog entry.
• XSP.partialRefreshGet(refreshId, options), XSP.partialRefreshPost(refreshId, options)
  Triggers a partial refresh manually. For POST the refreshId must point to a form, for get it can be any element with a partial refresh defines. The options object is quite interesting to examine. Includes parameters and functions to execute in the life cycle.
• XSP.attachDirtyListener(clientId)
  Listen to a specific field. If it changes consider the form "dirty". (Persil to the rescue). Use XSP.attachDirtyUnloadListener(message) to set a message. Typically you use that for "Your form has changed, do you really want to navigate away" type of messages.
• XSP.trim(string), XSP.startsWith(string, seachString), XSP.endsWith(string, searchString)
  Convenience functions for string stuff.
• XSP.serialize(object)
  Takes an JavaScript object and returns a textual representation. Currently JSON, but might change.
• XSP.toJson(object), XSP.fromJson(string)
  Convert data from/to JSON format.
• XSP.log(message)
  Send a message to the local log. Used for debug (mostly)

This is just an extract. I probably will cover usage details in future posts. You will have fun exploring more of it. As usual: YMMV

*Remark: Regardless what target environment environment you develop for: IE6, IE7, IE8, IE9, FF2, FF3, FF4, Opera, WebKit (The core of the browsers in iPhone, iTouch, iPad, Android, Chrome and Safari) or others, you do want to develop your XPages application using Firefox. The simple reasons are Firebug and Medusa.

Posted by Stephan H Wissel At 5:52 PM Location Singapore | Permalink | Comments (0) |      

Category XPages
My previous solution was designed for categorised views that don't use column totals. The difference between a view control with and without column totals is subtle but important. Without totals a category row is rendered with a colspan attribute that allows the categories to freely flow over the whole width of the table. Are column totals present no colspan is used and the column for the category must be wide enough to accommodate the full content. With a little JavaScript that can be fixed. The server side JS now looks like this:

Posted by Stephan H Wissel At 2:06 AM Location Singapore | Permalink | Comments (2) |      

Category XPages
When a body of knowledge reaches a certain size specialisation kicks in. So while we all can try to be like Leibniz or Da Vinci at the end some specialisation keeps us sane. With the growing body of knowledge in XPages you need to think where you want to go deep unless of course you are a Jack of all trades

There are different directions to go: front-end or back-end, business applications or common components.

• When you look at the back-end you want to understand the Domino server and storage in detail. You will encounter XPages' JSF underpinning and manage quite some beans. You will boldly go where "no LotusScript programmer has gone before". That is an area where knowledge of Java is a must. You might link XPages to host systems or RDBMS taking advantage of all the Java libraries at your hand
• Deep inside the back-end there is the OSGI extension model. You write your own components to extend the available capabilities. Most likely you don't write them for a single purpose but for general reuse
• On the front-end you want to understand JavaScript and the Dojo Toolkit. When you build shared components and controls you design them to be parameterised for easy reuse. The Dojo types you create can simply be used by your business developers in a declarative way. You have a good understanding of the IBM OneUI and reasonable CSS skills
• You are the UI guy. You know CSS inside out, as well as all the Browser quirks. You design new Themes

All these specialisation types were almost non-existent in classic Notes development and you actually can get away without them still building great Domino applications on XPages. You are the Lotus Domino Business application developer (a.k.a the Classic): You work with what is given. Only now the group of givers has grown (see above). You work with script and are OK to switch from LotusScript to JavaScript. The only thing you care about Dojo is to know the name of the controls to put in the XPages control properties. You are perfectly happy using the OneUI. AND: You understand your users (you always have), prototype applications rapidly and create happy users before morning tea break. That was what Notes and Domino development are about: rapid user satisfaction.

Posted by Stephan H Wissel At 7:22 PM Location Singapore | Permalink | Comments (3) |      

Category XPages
I am not a fan of categorized views in web applications and have suggested alternative uses before. However beautiy is in the eye of the beholder, so categorized views are used. When a category is rendered it sits on its own tablerow (tr) in a tabletag (td) that has a colspan attribute. This effectively disables the column width settings for your view until you expand the category to show a full row of data resulting in some "screen jumping". While that won't sink the Titanic it is a little odd. Short of rolling your own rendering using a repeat control, there is a fix consisting of 2 JavaScript functions (one for the server, one for the client and a little addition in the source code panel. This works in all categorized views. However when you have a column with a column total rendering might be different since XPages doesn't render the colspan attribute then. Lets get started. Open your source pane and locate the view panel and the xp:this.facets. Here you insert a scriptBlock like this: (Replace { } with < and > except inside the CDATA section). Then you add 2 JavaScript libraries to your XPage: CatViewPatches.js and TableSupportFunctions.jss. They will fix the column width. One caveat: you have to specify the width for all columns otherwise the unspecified columns get 100/{number-of-columns}% width assigned.

Posted by Stephan H Wissel At 1:33 PM Location Singapore | Permalink | Comments (2) |      

Category XPages
More goodness coming along in XPages 8.5.2 (Disclaimer: it is still Beta ...) An XPage is a collection, or to be precise, a tree of controls with an xp:view tag as root control. The xp:view tag translates into a instance of the UIViewRootEx2 class. In theory you could subclass this but then you stray far away from the path of IBM support. In some case (think Ajax updates) it would be nice if you could request the render result of just one control (and all its children of course). In 852 this is possible using the ?$$axtarget= directive. It takes the client id as parameter and requires a keyword (you can use to identify the action) between page name and directive. So your URL could look like this:
http(s)://[yourserver]/[application.nsf]/[Yourpage.xsp]/[SomeactionName]?$$axtarget=[ClientIDofTheControl]
The control doesn't need to check for the value of [SomeactionName], it is up to you if you want to use that. A sample function giving you the url for a given command and control could look like this (you want to add error handling for production use): As usual YMMV

Posted by Stephan H Wissel At 2:14 AM Location Singapore | Permalink | Comments (5) |      

Category XPages
In classic Domino applications directly addressing attachments is well known and simple. Your URL has the format:
http(s)://[yourserver]/[application.nsf]/[viewname|0]/[UNID|ViewKey]/$File/[AttachmentName]?Open
While this will continue to work on the Domino server for the forseeable future you want to learn about the XPages syntax. The very obvious reason: the classic Domino URL doesn't work in the Notes client (XPiNC) and you want to make your applications work cross-platform don't you? Also we don't know what additional options handling attachments via XPages might bring in the future. the syntax is a litte more complex.:
http(s)://[yourserver]/[application.nsf]/xsp/.ibmmodres/domino/OpenAttachment/[application.nsf]/[UNID|/$File/[AttachmentName]?Open
A few remarks:

• The URL contains the application location twice. From my tests it looks like the /__[ReplicaID].nsf/ doesn't work for here. I haven't tested what happens when you specify 2 different applications in the front and the back
• Since there is no view involved in the URL addressing attachments using an attachment key won't work. You have to use the UNID. This requires extra care when you build applications where the attachment URL is supposed to be shared (like send in a chat or an eMail). Deleting a document and recreating with an updated attachment will alter the URL. So ou want to cater for that case with a specific XPage rather than a raw URL.
• When you attachment is stored inside a RT field (e.g. using the upload control where you target a field) you can replace "/$File/" with the field name e.g. "/Body/"

To make my life easier I use 2 functions so I get an attachment URL with a single call:

Posted by Stephan H Wissel At 1:03 AM Location Singapore | Permalink | Comments (3) |      

Category XPages
Dates and locations updated!:
The release of Domino 8.5.2 draws closer and I'm happy to announce more training events (hosted by your's truly):

1. Beginners XPages: 10 Aug 2010, Auckland, New Zealand
2. Advanced XPages: 11 Aug 2010, Auckland, New Zealand
3. Beginners XPages: 12 Aug 2010, Wellington, New Zealand
4. Advanced XPages: 13 Aug 2010, Wellington, New Zealand
5. Beginners XPages: 17 Aug 2010, Sydney, Australia
6. Advanced XPages: 18 Aug 2010, Sydney, Australia
7. Beginners XPages: 19 Aug 2010, Melbourne, Australia
8. XPages for the Brisbane Lotus User Group: 20 Aug 2010, Brisbane, Australia

Posted by Stephan H Wissel At 1:29 PM Location Singapore | Permalink | Comments (2) |      

Category XPages
One of the unique features in Notes and Domino are form formulas. On a view you can specify a formula that alters the form used to show a form. This is very handy to show the same document reformatted for different stake holders, so they can focus on what is important to them

Form formulas are a tried and tested solution. So I was wondering what happens when you bring XPages into the mix.

Posted by Stephan H Wissel At 4:13 AM Location Singapore | Permalink | Comments (1) |      

Category XPages
In Tim's and my Lotusphere session AD111 we rendered data from an XPage into a ODT document. Once you get the hang of it and it is easy to implement export to text, spreadsheet or presentations. One nice aspect: no server side OpenOffice or Symphony code is needed. Here is how you do it:

1. In DDE use Window, Show Eclipse Views, Other (Alt+Shift+Q Q) and select "Navigator"
2. Locate the WebContent/WEB-INF folder and add 2 directories: src and lib
3. Download the Java toolkit from ODF Toolkit and add odfdom.jar to your WebContent/WEB-INF/lib directory
4. Right click on your NSF and select Project Properties. Then select Java Build Path. In the source tab add the src folder you created in step 2. In the Libraries tab add the odfdom.jar you copied in step 3
5. Create the class you want to use for rendering the content (rendering logic goes there). It should have a method that takes an OutputStream as parameter (I called it render)
6. Optional: define your new class to be a managed bean. Once you do that it can be used as if it is a native global variable. To do this locate the faces-config.xml in the WEB-INF directory and add a bean definition. Could look like this:
   

   <faces-config>
     <managed-bean>
       <managed-bean-name>stuff</managed-bean-name>
       <managed-bean-class>com.lotusphere2010.ad111.Sample</managed-bean-class>
       <managed-bean-scope>session</managed-bean-scope>
     </managed-bean>
   <faces-config>
   

7. Create a new XPage, go to the page properties, basics and set rendered=false. You can see in the XSP source
   <xp:view xmlns:xp="http://www.ibm.com/xsp/core" rendered="false">
8. Add code (see below) in the beforeRenderResponse event. It is important to use this event, so you can get hand on the OutputStream rather than the writer
9. The ODFToolkit requires one additional setting for security, so locate [NotesInstallDir]/jvm/lib/security/java.policy file (you need to do that on the server too) and add:
   grant { permission java.lang.RuntimePermission "shutdownHooks"; };
10. You are all set. Enjoy. As usual YMMV

Posted by Stephan H Wissel At 2:38 PM Location | Permalink | Comments (2) |      

Category XPages
XPages and server side JavaScript come quite some classes (and I'm not counting the Java classes you could use). We have:

• Class Library: DOM
  • DOMAttr
  • DOMCDATASection
  • DOMCharacterData
  • DOMComment
  • DOMDocument
  • DOMDocumentFragment
  • DOMDocumentType
  • DOMElement
  • DOMEntity
  • DOMEntityReference
  • DOMException
  • DOMImplementation
  • DOMNamedNodeMap
  • DOMNode
  • DOMNodeList
  • DOMNotation
  • DOMProcessingInstruction
  • DOMText
  • DOMUtil
  • NamespaceContext
  • NamespaceContextImpl
• Class Library: Domino
  • DirectoryNavigator
  • NotesACL
  • NotesACLEntry
  • NotesAdministrationProcess
  • NotesAgent
  • NotesAgentContext
  • NotesBase (recycle() is defined here)
  • NotesColorObject
  • NotesDatabase
  • NotesDateRange
  • NotesDateTime
  • NotesDbDirectory
  • NotesDirectory
  • NotesDocument
  • NotesDocumentCollection
  • NotesDxlExporter
  • NotesDxlImporter
  • NotesEmbeddedObject
  • NotesError
  • NotesException
  • NotesFactory
  • NotesForm
  • NotesInternational
  • NotesItem
  • NotesLog
  • NotesMIMEEntity
  • NotesMIMEHeader
  • NotesName
  • NotesNewsletter
  • NotesNoteCollection
  • NotesOutline
  • NotesOutlineEntry
  • NotesProperty (used in Mashups and composite apps)
  • NotesPropertyBroker
  • NotesRegistration
  • NotesReplication
  • NotesReplicationEntry
  • NotesRichTextDoclink
  • NotesRichTextItem
  • NotesRichTextNavigator
  • NotesRichTextParagraphStyle
  • NotesRichTextRange
  • NotesRichTextSection
  • NotesRichTextStyle
  • NotesRichTextTab
  • NotesRichTextTable
  • NotesSession
  • NotesStream
  • NotesView
  • NotesViewColumn
  • NotesViewEntry
  • NotesViewEntryCollection
  • NotesViewNavigator
  • NotesXSLTResultTarget
• Class Library: Runtime
  • I18n
  • Locale
  • TimeZone
• Class Library: Standard
  • Array
  • Boolean
  • Date
  • Function
  • Math
  • Number
  • Object
  • RegExp
  • String
• Class Library: XSP
  • DirectoryUser
  • NotesXspDocument
  • NotesXspViewEntry
  • XSPContext
  • XSPUrl
  • XSPUserAgent
• Function library: @Functions (with many functions- for the next time)
• Function library: XSP Functions (with many functions- for the next time)

That's it. Read the full list with all properties and methods.

Posted by Stephan H Wissel At 1:17 AM Location | Permalink | Comments (2) |      

Category XPages
XPages does a fe nice things automagically for you. Thinks like giving you the content of a view page by page. While this is impressive on the first view a lot of the potential users would like to see more options in that navigation/paging control. This got me thinking and I drafted how the "Ultimate View Navigator" would look like. After all Bob Obringer designed his classic Domino navigator partly based on my suggestions (Unfortunately Bob's blog is gone). So I doodled around with my favourite screen design tool and here is what I came up with:

I think it covers all the usual bases. A few caveats: It hasn't been designed for categorised views, but will display single category selections well (for my view on categorised views, check my earlier post). It also will not perform nicely when you use reader fields protected documents (and again that topic has been covered before). Did I miss anything in the UI?

Posted by Stephan H Wissel At 4:00 AM Location Singapore | Permalink | Comments (16) |      

Category Lotus Notes XPages
In Domino 8.5.1 we will have a new Design Element "Component". This design element can be used in Portal, Mashups and the Notes sidebar as iWidget as well as composite component in the Notes client. In a component you pick 3 XPages (could be the same for all 3 cases) for read, edit and help mode. You also define the events the components "knows" and what type of event is is for that component: sending, receiving or both. An event is associated with a data type that can be primitive (String, number), JSON or a complex data type you defined with that component.
Components are the Lego blocks of your applications. A system designer now can quickly build "empty" components wire them up and then leave the implementation to the XPages development team. This could accelerate Domino's RAD capabilities further.

Posted by Stephan H Wissel At 4:33 PM Location Singapore | Permalink | Comments (0) |      

Category XPages Show-N-Tell Thursday
Categorized views are kind of a trademark of Lotus Notes (Client) applications. We like them, we build them, we love them. We also want to see them on the web. There is only one small issue: That display of information is pretty unique to Notes. You do find this tree/table combination in other applications only to display files (like Nautilus, Finder or KDE) but not data. So a categorized view is kind of odd on the web. I played around to find alternate displays for single and multiple category data. Here is what I came up with.

• Single Category view with Listbox
  The category isn't part of the view itself but a picklist on the left (which might be filled by a @DbColumn). The table shows the current selection matching the selection. Works out of the box already today. Interesting extension challenge: allow selection of multiple entries in the listbox.
  
• Single Category view with Combobox
  A variation of the first theme. Useful if you have a lot of view columns and need the real estate on the left. Variation: Instead of the dropdown: show a link that uses a popup to allow selection of the category to show.
  
• Multiple Categories with Combobox
  This actually works also with a sorted view since the limit key takes an array as entry. As variation similar to the previous example could be to show a breadcrumb link list that allow to click or hover to show the selection. Challenge: How to make it obvious that you need to select/narrow from left to right. Extra challenge: when you change box 2 and the value in box 3 is no longer an available value
  
• Multiple Categories in tree/table combination
  Looks like a file dialogue, so users should be familiar. You trade horizontal space for vertical space. Makes navigation in categories more accessible since all categories are available any time
  
• Pivot view on 3 categories
  Category 2 becomes the columns of the table, Category 3 the rows. Adds sums to rows and columns. Good base material for graphs. Challenge: decide on the aggregation mode: sum/average/percentage -or- optional display of such a column
  
• Pivot view on 3 categories with data rows
  Similar concept like the previous but with individual data rows displayed. Might show additional aggregation rows or columns
  

Now someone needs to build all these custom controls. All the images have been build using Balsamip Mockups

Posted by Stephan H Wissel At 2:49 AM Location Singapore | Permalink | Comments (2) |      

Category XPages
We have scheduled 3 more XPages training classes in AP:

• 28/29 July, Jakarta - Indonesia (contact Gunawan for details
• 31Aug/01Sep, Seoul - Korea (contact Kim Ky Young for details)
• 22/23 Sep, Hanoi - Vietnam (contact Nguyen Hoai Nam for details)

And yes. Class delivery is by yours truly.

Posted by Stephan H Wissel At 3:18 PM Location Singapore | Permalink | Comments (2) |      

Category XPages
XPages is a constant topic when talking to Domino developers. One of my favorite questions to them is: "What (custom) controls are you expecting to use". The controls might exist, being build or being acquired. This is the unsorted list of what I heard so far:

• Names fields with address picker
• Custom address dialogs
• Numeric spinners
• Graphic controls connected to a data source
• Custom data sources control
• Controls supporting encryption/decryption
• Workflow controls
• Tagging input/Tag cloud from Lotus Connections
• Controls that are Sametime aware
• Chat controls
• Data filter control that looks like the Excel filter mechanism
• Tree control to render an outline
• Dialogbox control
• Login/User account control
• Pivot table linked to a data source
• Picture gallery controls in various forms and shapes including cover flow
• Task list controls (add this to a task in Notes or Activities)
• Notification control (send a message to notify others: eMail, Chat, Twitter)
• Document history controls
• Access control control (reader/author field management)
• Translation control (translate the DATA)
• Rating control
• Feedback control
• Shopping cart control
• Lotus Connections Business Card control
• Attachment control. Here I got multiple ideas around attachment management including Quickr integration
• "See also" control: add a link to the page
• Application Help control
• Comment control
• Expiry control (from just adding a date to sophisticated lookups in corporate policies databases)
• Media view control (Flash, Media players etc.)
• Inline edit control (edit one field without switching to edit mode)
• Spreadsheet control (with Export - thx John)
• Search control (from search in a view to Enterprise Search to Google search)
• Poll control (ask a question and render the results)
• ToolTip control
• "Print This" control
• PDF control
• Gannt chart control
• Scheduling control (using Quarz) for tasks
• Balsamiq Mockup control
• iLog Rule engine control
• Update: New control requests/ideas
  • Query Building control (Formula/FullText), thx Erik
  • Datasource merge control: Have 2 identical structured datasources and merge their content into a single grid/table
  • Login/Credential for SSO, thx Kevin
  • Transformation/Export control: transform the content of the pages into other formats. A superset of PDF/Spreadsheet export.
  • Paypal control: there are new more open APIs available now
  • Actionbar / Dropdown menu control
  • Right Mouseclick menu
  • Document lock/unlock control
  • Timer control: execute JavaScript and/or Ajax calls on time
  • Slilder control for views, data tables and repeat control

Interesting insight: We are seeing "small" controls like the names field as well as "big" ones like an entire Workflow piece. To be clear: that's what customers and partner said, that's *not* taken from any IBM ToDo list (or at least none I'm aware of). Some of these controls are already in the wild.
What controls are you looking to use in your application?

Posted by Stephan H Wissel At 4:59 PM Location Singapore | Permalink | Comments (7) |      

Category XPages
HTML has widely used and more exotic tags. Fieldset and Legend being of the later type. Theo reminded me, that they can be useful and asked how to incorporate them into a XPage. The best approach is to create a custom control with custom parameters and an editable area inside and simply type the html controls into the source code. The legend is rendered by a computed field, so translation will be able to pick it up.

The source code of the XPage looks like this (note: the custom property doesn't show up here since it is stored in a file hidden from the Domino Designer perspective):

<xp:view xmlns:xp="http://www.ibm.com/xsp/core">
    <fieldset>
        <legend>
            <xp:text escape="false" id="legendText" value="#{javascript:compositeData.legendText}">
            </xp:text>
        </legend>
        <xp:callback facetName="facetFieldSetContent" id="callbackFieldControlSet" />
    </fieldset>
</xp:view>

When using the custom control in a XPage or another control it looks like this (note the content inside the "this.facets") is what you put in there. can be a panel or table with fields in it or another control.
>

<xp:view xmlns:xp="http://www.ibm.com/xsp/core" xmlns:xc="http://www.ibm.com/xsp/custom">
    <xc:FieldSetControl id="MyFieldSet">
        <xc:this.legendText>This is the &lt;b&gt;legend&lt;/b&gt; text</xc:this.legendText>
        <xp:this.facets>
            <xp:panel xp:key="facetFieldSetContent" id="stuffInsideTheFieldSet">
                <xp:label id="label1" for="inputText1" value="Test Field">
                </xp:label>
                <xp:inputText id="inputText1" />
            </xp:panel>
        </xp:this.facets>
    </xc:FieldSetControl>
</xp:view>

As usual: YMMV

Posted by Stephan H Wissel At 2:10 AM Location Singapore | Permalink | Comments (3) |      

Category XPages
Domino 8.5.1 went into controlled beta recently. While others do performance testing provide us with and performance tips I poked around detail improvements. One of the early tips to integrate dojo components into XPages is to use a DIV wrapper. In 8.5.1 this is no longer necessary, since you now can specify dojoType and dojoAttributes directly on a panel (and some other custom controls). A nice step to cleaner code

Posted by Stephan H Wissel At 10:55 PM Location Singapore | Permalink | Comments (0) |      

Category XPages
Today I completed a short introduction into XPages for a business partner in Xi'an. Initially the participants were a little stiff:

But with food and demo (click on the picture above) they warmed up to the new way of doing things. I'll spend the weekend in Xi'an visiting one of the five holy mountains of the Taoist: Mount Huashan. I'm curious how this will work out.
I'm pleased to announce, that I will conduct another XPages workshop, this time in Hong Kong. (Update: Date for HK has changed!)The class will be on the 06/07 July 2009 and is open for registration. For details, location, fees etc. please contact Tony KT Lee from IBM Hong Kong.

Posted by Stephan H Wissel At 1:17 AM Location Singapore | Permalink | Comments (2) |      

Category XPages
In his outstanding XPages tutorial Declan Lynch used IBM's OneUI for designing the layout and colors. This is very smart since it releaves you from thinking about all this and allows you to focus on the functionality. If you haven't worked through that tutorial, go there now and have a look. One thing Declan had a hard time with is to figure out what exactly the CSS classes are that the OneUI makes available - He did a great job here - (and then what to use where) since the CSS style picker doesn't show the classes available in the Themes, but only in the CSS you added to the page directly.
I thought that's not that nice and needs fixing. And here you go: Import the OneUIDummy.css into your database and add it to your pages. The file contains all classes used in the OneUI version on the Domino 8.5 server but no style definitions by its own. You now can pick the classes from the style picker and actually use the definitions in the server-side OneUI Theme. A little step for a developer and a big step for convenience. (You still need to learn what class to use where).

As usual: YMMV.

Posted by Stephan H Wissel At 7:23 PM Location Singapore | Permalink | Comments (4) |      

Category XPages
I pride myself with being able to help students quickly over their stumbling blocks. But is made me stumble:

A good spatial memory and an aptitude for icons helps a lot. We are definitely having fun here.

Posted by Stephan H Wissel At 5:37 PM Location Singapore | Permalink | Comments (1) |      

Category XPages
The XPages workshop in Taipei is well under way. We have 32 participants at the IBM Education center happily coding away on Domino Designer 8.5. The joy of travel is to experience all the little cultural differences. Like the coffee bar:

Only one of the cans actually contains coffee. The other 3 (x2) cans offer you different sorts of tea freshly brewed. I like that much better than the tea bags you find in other locations. Maybe that's the reason why the class is so fully focused.

There will be more workshops in Taiwan, Cory Ma knows the details.

Posted by Stephan H Wissel At 1:20 PM Location Singapore | Permalink | Comments (2) |      

Category XPages
The XPages workshop proved to be very popular. About 30 participants showed up to get their take on web2.0 development with Domino Designer 8.5. Impressions from earlier workshops got confirmed:

• Everybody loves XPages
• Developer with a background in web development grasp XPages faster than classical Notes developers
• Exercise 17 is the most difficult one, but everybody can complete it
• The XPages outline (in the default Domino Designer perspective on the lower left) is a huge time saver navigating your XPage
• Having the ability to inspect the source code can accelerate trouble shooting tremendously
• A modal window to enter code is a nuisance

For business partners the workshop run as "bring your own laptop". To my surprise quite a number had Windows ME 2009 Edition Vista on their machines and quite some trouble getting the local preview of Domino designer to work. This is a known problem that plagued others too but has been solved one way or another. Just keep in mind: Never ever install a data directory inside the place where programs go (I think we need to adjust our installer defaults) and be clear what runs/blocks Port 80. Look out for Skype (can be switched off in the settings), Firewalls, Webservers etc.

Posted by Stephan H Wissel At 7:36 PM Location Singapore | Permalink | Comments (1) |      

Category XPages
One of the very cool features in XPages is the ability to create your own custom controls. While on the first look one could say "well, they are just subforms with a new name" the second look shows bigger differences:

• Custom controls can appear more than once on a page, subforms only once (yes there was the possibility to add a subform twice if it didn't contain any fields, but that was not intended)
• Custom controls are self aware: they "know" what is inside and what is outside
• Custom controls have parameters. You can define parameters that the custom control will address as CompositeData.[parameterName] and the hosting pages address as [controlName].[parameterName]

When you look at the source code of a page you can clearly see the parameters you might have set for a custom control. However when you look at the source code of your custom control, you won't see any definition. Puzzled me for a moment, so I asked the master. At the very end XPages is a JFS application. In JFS a custom control has 2 files (at least): the code and the definition. XPages shields you from the complexity by allowing you to edit everything in one UI. But if you *really* want to have a look, add the Navigator window to your Domino Designer perspective and navigate to the custom control directory. Here you will find MyControl.xsp as well as MyControl.xsp-config. If you want to understand what the containing XML is all about, take a peek at a JSF tutorial

Posted by Stephan H Wissel At 3:08 AM Location Singapore | Permalink | Comments (5) |      

Category XPages
We have new dates for XPages workshops:

• 8/9 April 2009 - Bangkok, Thailand (Business Partner only, contact Nithitus Upatumvipanon to sign up)
• 6/7 May 2009 - Singapore (Business Partner only, contact Beng Chong Lim to sign up)
• Australia: Public classes
  • 29/30 Apri 2009 - Melbourne
  • 25/25 May 2009 - Sydney

Places are limited, so be quick.

Posted by Stephan H Wissel At 4:00 PM Location Singapore | Permalink | Comments (7) |      

Category XPages
Last week I conducted our famous XPages workshop in Kuala Lumpur and this week in Manila. I found a high number of encouraging pointers:

• participants generally love XPages
• In both classes more than half of the participants had no or less than 2 years experience with Lotus Notes and did quite well
• One customer shared: "We haven't developed new Domino applications for a few years now, but with XPages we will resume creating new applications for the Lotus Domino server"
• Developers with exposure to web development snap XPages up easily, old Notes hands need to unlearn a few things first
• The repeat control is everybody's favourite measured by the time they spend with that exercise (repeat after me: with great powers comes great responsibility)

Next stop: Melbourne, Australia 29/30 April 2009.

Posted by Stephan H. Wissel At 4:01 PM Location Singapore | Permalink | Comments (2) |      

Category Show-N-Tell Thursday XPages
In our XPages workshop we have a number of exercises that deal with validation. XPages allows you 4 different approaches when and how to validate (not counting the on-field-exit validation which is a very bad habit anyway - never validate on exit, just hint, that this will not submit):

When you look at applications you typically find validation code in the submit button or attached to the submit event (that would be the second from left). While that is wide spread it is not the best way to do that in XPages. Looking at the possibilities we have 2 discussions: server vs. client, validator vs. Button/Event code. You have to be clear about the execution sequence: when a validator fails the submission code isn't executed. If the client validation (by any means) fails no server validation takes place.

• Client side validation has the clear advantage to give faster feedback, since no round-trip to the server is required. However it only can be used as a measure for user convenience since it can be canceled out using the appropriate tools (Firebug anyone) easily. Client side validation needs all information for the validation downloaded into the client. So you are limited to simple validations like required fields, consistency checks, data types etc. Anything that requires server information (e.g. Is there budget left, is this the right approver) better lives on the server side. Also currently the client side validation in XPages relies on a simple alert() to notify of validation failures and users are fast as lightning to click away prompts without reading them.
• Server side validation requires a round trip to the server (full page or a ajax call), so it will take longer. On the server side you can rely on any resources or lookups to protect data integrity. Also server side validation is less prone to manipulation (you would need access to the server sources). In XPages you also have better UI capabilities.

In conclusion: Client side is for convenience, server side for the "real stuff".

• Validation in code (a button, the submit event etc.) is a typical way validation is done. Being the prevalent way doesn't make it right <g>. You need to roll your own notification mechanism (like updating a label) and tend to tie your validation into the UI. Also when you remove a field the validation routine is likely to break. Last not least: you have a hard time documenting what gets validated and why. (You see where I'm going with that)
• Validators are defined together with a field and open a series of posibilities. XPages offers 9 different validators.
  
  You can write JavaScript, regular expressions, check for data types or roll your very own. All you can do in a button/event code you can do in a validator. Since the validators themselves don't interact with the UI the designer can decide how to surface the messages without changes to the validation code. When you remove a field all its validation code goes with it, so maintenance gets much easier. Last not least: you can run an XSLT report against your XPages source and render a report that shows a field with all the defined validators, which makes documentation easier.

In conclusion: Validators are the way to go. Read more about it in the Domino Designer WIKI on IBM DeveloperWorks.

Posted by Stephan H Wissel At 2:18 PM Location Singapore | Permalink | Comments (3) |      

Category Lotus Notes Show-N-Tell Thursday XPages
XPages feedback from an early adopter:"I'm now able to call our code from an XPage... and equivalent transactions that were taking a full second (or more) to complete in a Domino agent are now completing in 20 - 40 milliseconds. And we haven't even optimized it yet; that 50x performance boost is just from running it in XPages instead of in agents."
What do you want more?

Posted by Stephan H Wissel At 5:41 PM Location Singapore | Permalink | Comments (0) |      

Category Lotus Notes XPages
Tim sums it up:
So it seems that word is spreading about this great XPages stuff, (so someone does read my blog) and I am being asked what the plans are to deliver it in other countries. January is going to be planning month and Lotusphere 2009 So here is who to contact if you want to add you name to the list of people/countries that are interested.
to find out how to contact them you can use the WhoIs application.
Only Stephan and I know about this blog post so far so when you contact the others, please be gentle. ;o)

• EMEA: Tim Clark Please leave comments on this post to show an interest for EMEA.
• Asia Pacific: Qiao Ming Chen for China, Stephan Wissel (me) for Asian & India, Atsushi Sato for Japan
• ANZ: Craig Hart for Australia / New Zealand
• Americas: Craig Wolpert

Posted by Stephan H Wissel At 1:30 PM Location Singapore | Permalink | Comments (2) |      

Category Show-N-Tell Thursday XPages
In Domino Agents are the Swiss Army Knife of development. They can be called from the client, triggered on schedule, automatically run on an event, be associated with a web action (Open, Close) or directly called from an URL using ?OpenAgent. The ?OpenAgent use of agents is subject of this blog entry. A agent triggered from an URL can use Print statements to output results back to the browser. When the first line of your print statements is "Content-Type:..." you also can serve XML or JSON or whatever exotic format your agent logic was able to conceive. Agents come with the usual drawback: the runtime environment is intitialized new for every agent run, so you need to update a document if you want to keep track (Replication conflicts anyone?)
XPages don't have a notion of agents (you can call them in the backend, but you won't get anything back from the print statements), so it seems a step back. On closer inspection however one can see, that XPages offer a greater flexibility for the same pattern of use. Every element on an XPages has a "render" attribute which determines if the element should be rendered. "Every" includes the page itself. So when you set the page's render property to false, well the XPage engine renders nothing. So you get an empty canvas you can paint on. XPages still provides you with the page event and access to scoped variables, so you can code better performing "agents" since you can keep lookups in memory. To get the equivalent to the LotusScript print you need the ResponseWriter from the externalContext. To set the content type you use the response.setContentType also to be found in the external Context. A sample snippet you could put in the afterRenderResponse event of your page would look like this (error handling omitted):

// The external context gives access to the servlet environment
var exCon = facesContext.getExternalContext(); 

// The writer is the closest you get to a PRINT statement
// If you need to output binary data, use the stream instead
var writer = facesContext.getResponseWriter();

// The servlet's response, check the J2EE documentation what you can do
var response = exCon.getResponse();

// In this example we want to deliver xml and make sure it doesn't get cached
response.setContentType("text/xml");
response.setHeader("Cache-Control", "no-cache");

// Here all your output will be written
writer.write("<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<christmas date\"24Dec\" />");

// We tell the writer we are through
writer.endDocument();
facesContext.responseComplete();
writer.close();

More information about the FacesContext can be found in the Domino Developer Wiki.

Bonus Tip: Since you do not render anything from the XPage you just used, why not take that empty page and write the documentation for that XAgent?

Posted by Stephan H Wissel At 8:20 PM Location Singapore | Permalink | Comments (19) |      

Category XPages
Yesterday I mused about how you can add a Domino 8.5 xPages server to an existing Domain without changing the existing infrastructure. Looking at the picture I realized, that while its function seems to be obvious, it actually might only be obvious to the initiated. So I went back to the drawing board. In a typical web application setting using other technologies (like JSP, ASP or PHP) you typically have a web server, an application server and a database server (they can and do sit quite often on the same physical machine). This is well understood by almost all IT decision makers. So for a Notes application web enablement you need a web server. This would look like this:

You add a "Web Frontend Server" to your existing infrastructure. It is like adding an Apache to an Oracle database or MS-IIS to MS-SQL. The nice thing in the Domino stack however is, that you don't need to acquire new skills to administrate this "Web Frontend Server". The box is simply your's truly Domino 8.5

Posted by Stephan H Wissel At 2:10 AM Location Singapore | Permalink | Comments (1) |      

Category XPages Show-N-Tell Thursday
I'm running the XPages enablement workshop in Beijing this week. Having to teach other about new functionality guarantees either dispair or insight. Today I had a rather insightful moment. Very often the NSF gets blasted for being a "flat-file-non-relational-whatever" file. When having a closer look at the format however you will realize, that it is a quite amazing part of technology:

• Build to function as a "whatever-you-want-to-dump-into" data store
• Build backward compatible. I still can open R2 databases in my R8.5 client
• Build to run on a client and on a server with high concurrent access
• Build to be robust: event if you tourture it (diskspace, sectors etc.) it will mostly recover
• Build to provide fulltext search access
• Build to be what you want it to be: if you happen to be a Notes client or a Domino server, it is a repository for design elements and a document database. If you happen to be the Eclipse IDE (or a webDAV client) it is a file system. If you happen to be the XPages server task it is a WAR application store. And if you happen to be David Allen, it is your trusted system for Getting-Things-Done

Posted by Stephan H Wissel At 9:03 PM Location Singapore | Permalink | Comments (0) |