Community Notes In 9

Announcing the NotesIn9 Hackathon: Race to 199

hackathon-MediumIt’s time.

It’s time for me to get off my duff a little bit and try and “kick this up a notch”.

It’s time for YOU who are reading this post to get a little more involved and “Join the Conversation”

To me a Hackathon is an event were people come together to contribute small pieces to complete a bigger puzzle.

I’ve been thinking of this ever since someone came up with the #CodeForTim hashtag.  When we lost Tim, I changed the motto of NotesIn9 to “Learn, Code, Share” to honor my friend and better reflect the mission of NotesIn9.  Well that’s what this Hackathon is all about.

I want to try and increase the output of NotesIn9. More shows with a better range of subjects.  I want to try and get NEW CONTRIBUTORS. And I want to try and get more questions, answers, ideas, comments and discussion going.

Typically when I get a new contributor on the show, it’s someone I’ve noticed and I’ve reached out to them privately and begged, pressured, or plain out annoyed them until they decided to come on the show.

Today I’m calling for Open Submissions.  If you’re working with XPages – no matter how basic – you have content you can share.  Think up an idea and email me and lets talk about it!  There’s no reason to be scared. You do NOT need to be an “expert” on the topic.  If you do a show the worst possible outcome is that someone comments that there’s a better way to get the same result.  Now you and others will learn that better way.  Win Win!  If you simply can’t share, because your company forbids it, then start leaving comments by asking a question, validating the material or simply just thank the contributor for their effort.  Let your voice be heard!  The more comments and people interacting, the easier it is to get contributors on the show.

I’ll post later some suggested topics but pretty much everything is open to discussion.  Even non XPages based shows. Learning is learning.  Period.

Unlike when I did “DriveTo99” a couple years ago there’s no “End Date” for this.  I’m going to push until we get to 199.  Then I’ll likely take a vacation.  🙂

So what’s in this for you?  I firmly believe the more you share the more you gain.  You start by gaining knowledge, experience, and confidence. From there you might gain friends, start speaking at different events and who knows, maybe even get a dream job. That’s what happened to me.

In the event that isn’t enough there will even be prizes!  Details will be forthcoming.

Let’s all see what we can build and then let’s all share it!

My email address is dleedy at notesin9 . com

I look forward to hearing from you.

Learning XPages Notes In 9 Podcast XPages

NotesIn9 145: Simple Feedback in XPages

This is the last show I have from Tim Tripcony.  This is probably the simpliest demo he’s done for Ni9 but no less important.  It’s a demo of a way to return a message to a user based on an action.

Tim actually gave me this demo maybe a year ago and I just totally forgot about it and I assume he then did as well. While I hate the thought of forgetting about it I think it makes this show a little special.  I was so happy to discover it when I went through our shared dropbox.


Java Podcast XPages

NotesIn9 144: OAuth for Domino Walkthrough

In this show Tim Tripcony explains how to get your Domino server to PROVIDE OAuth credentials and services.




Note: This show is a odd resolution because Tim sent me his demo at a bigger size then normal.  Because of this I’m not sure if it will play on mobile devices.



Community Notes In 9 Podcast XPages

NotesIn9 143: Component vs Value binding in XPages

In this show Tim Tripcony explains that while we’ve typically been binding to a value all this time, it’s possible to bind to a component inside your XPages Development.

This show was originally published elsewhere and I basically grabbed this to try and improve the visibility and get Tim’s information as much exposure as possible.

I have 2 new unpublished videos from Tim coming next.


Community Learning XPages XPages

Tim explains JSON-RPC #codefortim

First I want to highlight OpenNTF’s recent post regarding Tim’s projects.  Let me simply say that I think the #codefortim idea is brilliant. Pure genius and so appropriate.  Tim shared.  Period. I just read that post like 5 minutes ago so I’m going to let it sink in before I talk any more about it.

Which brings us to the topic of today.  This email exchange I’m going to post was forwarded to me by my friend Dan.  He asked Tim a question and as usual got a great response back.  I’m so very thankful he sent this to me.  What make this really special is just how recent it is.  It was only a couple of days before Tim passed.  This is the last email I have to publish.  If anyone has any similar emails that they’d be willing to share I’d be very happy to publish them as well. Next up is some videos.

Dan asks:

On May 7, 2014 at 4:30:20 PM, Daniel wrote:

Hi Tim,

I was looking at an answer you gave Naveen on Stack Overflow on the use of the JSON-RPC control.

From how you describe the control, it sounds like an AJAX operation. Is my understanding correct?

I’m thinking of an application for it and I wonder if you could tell me if it’s the right tool.

I have an Xpage I’m building that accepts input from a proximity scanner. When an ID is scanned (badgeNo), I’d like to be able to query and SQL db to get the person’s EmpID number and use that to display his image on the screen. Would the JSON-RPC control be appropriate for that kind of operation?



Tim responds:

From:        Tim Tripcony

To:        Daniel

Date:        05/08/2014 02:15 AM

Subject:        Re: JSON-RPC control

In my opinion, that use case is almost definitely a good fit for JSON-RPC.

RPC stands for “remote procedure call”. Simply put, you’re telling the server to run a method — and how to run that method (in other words, passing method arguments) — and send back a result. So yes, this is AJAX, but it’s slightly different from partial refresh events in XPages.

Partial refresh events execute server-side code, of course, but upon completion they send back a specific visual representation of a portion of the page (namely, HTML) because that portion of the page might need to look different afterward as a result of the execution of that code. The archetypal example of this is an onChange event in a combo box that alters which select values are now valid for an additional combo box further down the page. As you’ve no doubt already seen in action, the platform automatically generates the JavaScript for you that causes the AJAX call to tell the server what code to run, but also handles taking the HTML that is returned and updating the affected portion of the page.

Similarly, submission of any data the user has entered is also automatic. While there are ways to override exactly how much data is sent for each specific event, the default is to just post the entire form to the server. This facilitates the “statefulness” of XPages — with each event, the server state of the page is essentially synchronized with what the client state now is, so both the browser and the server have some level of awareness of the user’s behavior, and both can account for that current state.

JSON-RPC, by comparison, might appear rather manual at first glance. Adding one of these components to your page and defining one or more methods is essentially defining an API that you can then call… but you still need to then add client-side code to actually call it, and also to respond to whatever data the server sends back to the browser. There are a few bits of good news in this regard, however:

– The platform still auto-generates some client-side JavaScript for you. To be precise, a global JavaScript object is created client-side and populated with methods that map to whatever server-side methods you defined for the RPC. These methods are even aware of what arguments you defined for each.

– The performance of this type of service is incredibly lean for two reasons. One reason is that it sends the absolute minimum amount of data in both directions. To be precise, it sends only identifiers for which service is being called and which method it should run, as well as the value of any arguments; in return, it sends back only whatever value you explicitly return from whichever method is called. So instead of posting the values of potentially dozens or even hundreds of fields and getting back a big blob of HTML, it might send only a single number (e.g. badge ID) to the server and get back a single string (e.g. employee ID)… although the response object can be as simple or complex as you want.

The other reason it’s faster is because the default behavior is to not save the component tree after an RPC method runs. It’s assuming that you’re doing something very similar to the use case you described, so there’s no need to re-serialize the entire page state, because you’re not sending a bunch of form data that should update a backing model bean, etc.; rather, you’re just sending it a badge ID and asking it to send back a corresponding employee ID, so there shouldn’t be a need for it to “remember” that it did once it has.

For both of these reasons, JSON-RPC tends to be lightning fast when compared to most partial refresh events, even under low-bandwidth / high latency conditions.

Here’s some pseudo-code to give you a feel for what this might look like if you decide to take the JSON-RPC approach. Somewhere in your XPage you’d have component markup that looks similar to the following:

<xe:jsonRpcService id=”scannerRpc” pathInfo=”scanner”>


<xe:remoteMethod name=”getEmployeeId” script=”return getEmployeeIDFromSQL(badgeId);”>


<xe:remoteMethodArg type=”number” name=”badgeId” />





The assumption, of course, is that the getEmployeeIDFromSQL() function is already defined somewhere — presumably, in a SSJS library. So for what you’re describing, all that might really need to change in the above example is to alter the type of the badgeId argument (if, for instance, that should be a string, not a number) or to change the getEmployeeIDFromSQL reference to whatever code will be responsible for actually performing the SQL query, whether that be SSJS or perhaps a method of some Java bean.

The other half of this, then, is defining client-side code to call the remote method defined above. If that’s triggered by a “Search” button, for instance, you might end up with something like this:

<xp:button value=”Search” id=”button1″>

<xp:eventHandler event=”onclick” submit=”false”>

<xp:this.script><![CDATA[var badgeId = someCodeToGetIdFromScanner();


dojo.byId(“#{id:employeeId}”).attr(“value”, employeeId);




You might, of course, be setting the innerHTML of a div instead of the value of an input, but hopefully the above example illustrates the basic premise:

– Because the JSON-RPC service lists “scanner” as the value of its “pathInfo” attribute, the browser will automatically be aware of a global JavaScript object called “scanner”.

– Because the RPC service defines a remote method named “getEmployeeId” that accepts a single argument named “badgeId”, the global client-side object has a function called “getEmployeeId” that is also expecting a single argument.

– Calling that client-side function does not immediately send the AJAX request; rather, it returns an object that has a .addCallback method. Calling this method does immediately trigger the AJAX call… and passing a function to addCallback() defines what code will run when the AJAX call returns. Since we’re just expecting to get back a single string value, we specify that the function that we pass to addCallback() accepts a single argument, which we can then use inside the function to somehow update the page or otherwise inform the user that we now know what the scanned employee’s ID is.

No doubt there’s a myriad of valid approaches for your specific use case, but I’ve become rather fond of JSON-RPC for this type of functionality, both because of the relative ease of implementation and because of the comparative performance. Hopefully this overly verbose explanation gives you an indication of whether or not the JSON-RPC approach would, in fact, be a good fit for what you’re trying to do. 🙂

For anyone reading this information that’s interested in the JSON-RPC stuff.  I believe it’s come up on NotesIn9 a couple times as well. So there should be some examples available.


Community XPages

Tim Explains: SSJS Object Persistence

Below is an email thread between Serdar Basegmez, Tim Tripcony and myself. Serdar reminded me of it and re-sent it to me so I could share.  It’s a little dated but I’m reposting this because the quality of the information should be shared.

This is pretty much the marks the beginning of when I came to grips and realized that if I wanted to use XPages in a similar manner to how I developed for the Notes Client I needed to look past ServerSide JavaScript and focus on Java.  I liked building my applications around Custom Classes in LotusScript.  This email explains how that is no longer possible to do in XPages and that if I wanted to continue my client development “comfort zone” I needed to use Java for that.

Now this realization did not happen over night for me.  I believe this email came in right after my famous battle with Phil Riand. Where I said I’ll never use Java and SSJS should be made better and the “bug” should be fixed.  And he said it’s not really a “bug” and to use Java. we went back and forth a bit and I ended up losing royally and now I write with Java.  haha


So anyway here’s Serdar’s original question:


NotesIn9 and Blog publishing plans for Tim’s material

I guess I just wanted to give everyone a heads up on my current thoughts on publishing material that I have from Tim.

I have 2 emails filled with “Tim Info” that I want to publish and just get it out there.  1 is pretty old but the other was forwarded to me last week and I think was from that past Thursday.  Both have some really good information that deserves to be more widely available I think.

I also have 2 videos from Tim.  One from a couple weeks ago on using OAuth.  Another small one from a couple months ago that I just totally missed and forgot about.

There’s also a video from a while ago that was intended for NotesIn9 but I think I was on vacation that week and he just got impatient and put it up on his YouTube Channel.  I pretty much intend to republish that inside NotesIn9 so try and get it more visibility.

Anyway – that’s my thoughts.  My current intention is to get all this out as soon as possible.




Learning XPages Notes In 9 Podcast XPages

NotesIn9 130: Using XPages Type Ahead for Navigation.

In this episode Tim Tripcony makes a brilliant return to the show with a great demo on using “Fancy Typeahead” as navigation.  This builds on some previous examples on Type Ahead that you might want to look at as well.

— This is the really important one for Fancy Typeahead

P.S. This show has been released at a different resolution.  I usually try and stay with 1280×720 but Tim’s demo was 1980×1080.  Bigger is better when working in Designer so please let me know what you think.  If the resolution is ok or if it cases a problem.  If it’s all ok then maybe I don’t need to keep worrying about staying within the 1280×720.  Let me know what you think!