Technique: Using a Page as a cross language template/string container

In this demoapp, I use a page as a definition for an XML-representation of a document. It is related to a project at work, where we send XML to a web service. This service is to be called both from the Notes Client, and from an XPage. I could script the XML in both the agent and the XPage, but this could easily develop into a maintenance nightmare.

In the demo, I've used the body of a page as a token string (separated by ¤). The first token is the field-definition. This is to be used in a formula evaluate towards a NotesDocument. The second part is the template itself.

"first_name":"last_name":"company":"address":"age"
¤
<character>
 <first_name>[first_name]</first_name>
 <last_name>[last_name]</last_name>
 <company>[company]</company>
 <address>[address]</address>
 <age>[age]</age>
</character>

By having the field-definition in the page, you just have to update the page if you want more field values.

I wrote three different script libraries, each having more or less the same functionality. One LotusScript library, one Java (Script) library, and one ServerSide JS library. The libraries contain functionality that extracts the body of the a page based on its name (using a NotesNoteCollection of the pages in the DB).

I also wrote a LS agent, a Java Agent, and a XPage (acting as an agent). Each of them prints XML (based on the template) for the first document in a certain view.



This technique can also be used if you have a big string that is used in code written in multiple languages. If it's Java-code you're writing, and need a big string, this may be an easier way to maintain the string. Another thing that occurs to me is if you generate the same XML/HTML/etc. in multiple databases, you can maintain the String-template in one database, and use Design inheritance to spread it (or get the page from another database using otherDatabase.CreateNoteCollection(false)... )).

As with all techniques, this might not be the right tool for your job. Weigh pros and cons before you decide to use it/not use it.

>> Download DemoApp (open the app in a browser to test the demos)

Comments/critique/bugreports are as always welcome. :)

Not satisfied with Domino Designer documentation? Make your voice heard!

Got this in the mail yesterday:
Key team members are available exclusively on the LotusUserGroup.org
moderated forum through this Friday to read your feedback, respond,
and provide insight regarding functionality and content. All
questions, opinions, experiences, and feedback are welcomed.

Lotus Domino Designer documentation moderator team includes:
- Bob Harwood, the Information Development (ID) Lead for Domino
Designer
- Cara Viktorov, ID Customer Feedback Lead
- Steve Shewchuk - Designer ID manager
- Deanna Drschiwiski - Designer Information Architect
- Michael Stewart - Writer
- Bob Perron - Writer

See what your peers have already posted and participate at
http://www.lotususergroup.org/lotusforum

Domino Designer Forum

Avoid using reserved words in JavaScript

A former colleague of mine had an obscure problem with one of his applications. As far as I understood him, there weren't thrown any errors, but the application behaved weirdly in some situations.

Turned out that the cause of the problem was that he used a had a variable called name. name is a reserved word in the JS implementation of the browser (at least in IE).

While I can't remember the last time I stumbled onto this problem, I'd thought I'd share a list of reserved words in JavaScript/the browser implementations of JavaScript, in case any of my readers struggle with this.

To be on the safe side, never call a variable the same as a reserved word.

Interesting talk about Server Side JS

From YUI theater.

Some valid points about advantages with programming in JS in the client and on the server.

Finally! CKEditor integration with Lotus Domino

It's been over a year since I posted my demoapp of FCKEditor-integration with Lotus Domino.

The CKEditor (the new and improved!!! version of FCKEditor) has been out for a little while now. At first, the upload integration wasn't documented, so I didn't want to waste time reverse engineering the functionality.

I got a mail a couple of days ago from a reader about CKEditor-integration with Domino. I replied that I would create a demoapp of the integration as soon as the upload functionality was documented. Now it is (more or less).

The new API for FCKEditor is BIG, but that doesn't show on the CKEditor. Its fast as *insert something extremely fast*. Test out their demo if you don't believe me!

The only thing that's changed since the FCKEditor demoapp is the $$Return on the (f)ckupload form, and the hooks I use to rewrite the name of the upload field.

I tested the demoapp in IE8, Firefox 3.5, and Opera 10. Let me know if it doesn't work for you.

CKEditor must be installed in the ..data\domino\html\js folder (you have to create the js folder if you don't have one already). Test http://yourdomain.com/js/ckeditor/ckeditor.js to see if CKEditor is in the correct folder.

This also works on localhost, if you want to experiment on your own computer.

Read the FCKEditor-integration with Lotus Domino post as well. I may have forgot to mention some details.

Anyways, it's time to go to bed. Another day, another dime tomorrow.

>> Demoapp of integration with CKEditor

XPages Custom Control - getComponent/hash of all clientIds from the browser

Until IBM implements getComponent in the browser, I've made a litte experimental custom component that lets you do something similar to getComponent in server side scripting. So far it only works with unique components (doesn't work with repeated items).

The component adds a script-tag at the bottom of the page, using the output stream that you get from facesContext.

The API is small:
Application.renderedIds
An object containing { designerId: clientId(s) } for all (?) components in the XPage. If there are multiple versions with the same designer id, you'll get the wrong id. (see comments)

Application.getComponent( designerId )
Similar to the getComponent in Server side JS. Fetches the rendered id from Application.renderedIds, then uses the corresponding clientId in a document.getElementById-statement. This method will fail if you try to multiple controls that has the same designerId (repeated items for instance).



Comments/bugreports/wishes are appreciated (but I can't promise anything).

I'm probably going to start working on a big XPage application along with some colleagues in the near future, so it's not impossible that I might turn this into a client side utility component. Time will tell.

>> Demoapp with Custom Control (GetComponentClient)