Notes In 9 Podcast XPages

NotesIn9 196: No Dependency Page Controllers

We’ve talked about using page controllers before on the show, but typically I’ve used an external library. Today I’ll show a way to get started with page controllers with no external dependency.
I consider my move to page controllers as one of the best things I’ve ever done as an XPages Developer. Now there is no excuse for you to not consider using page controllers in your XPages applications.

Notes In 9 Podcast XPages

NotesIn9 195: Use XPages To Fill a PDF Form

In this show I demonstrate how to take an existing PDF form, and use iText from inside XPages to populate fields on the form.

Notes In 9 Podcast XPages

NotesIn9 194: Upload Files With PLUpload

Who likes the built in XPages File Upload Control?  Well not me at least.  In this show I’ll demo how to use PLUpload to better upload multiple files to your XPages application.


Notes In 9 Podcast XPages

NotesIn9 193: Force User Logout from XPages

In this show I’ll demo how you can add some code to your application to force a user to logout after a certain period of inactivity.
Thanks to Steve Zavocki for the original blog post that this show is based on.


Community Notes In 9 XPages

NotesIn9 makes it to 199 EPISODES!!!!

Yeah baby!!! That’s how we roll.

7 Episodes from my Epic session at MWLug 2016!!  All XPages.  The grand Finale makes my head hurt!  There’s code slinging in that one.

Look for them to be published very soon.  But for now.  I sleep!  haha


Sorry – a little punchy at the moment  🙂

Java XPages

NotesIn9 192 : Intro to Graph Database in XPages

In this show IBM Champion and all around amazing developer Oliver Busse returns with an EPIC demonstration where he talks about using Graph Databases inside the XPages/Domino world.  I’m far from an expert on them but Graph Databases are what the “Big Boys” like Amazon, Twitter, LinkedIn, etc.. use to more effectively maintain data that relates to other data.  Now you can get started with this inside you’re familiar XPages environment.

This is definitely a show not to be missed!

Note: YouTube is still processing this video. It should be ready shortly.

Learning XPages XPages

Want to talk XPages?

In case you’ve missed this we have an XPages Slack chat.

Beginners are WELCOME!! If you’re not already there please join, say hello and talk XPages. You don’t need to program alone anymore.

Learning XPages Podcast XPages

NotesIn9 190: Barcode Scanning in XPages

In this show I demonstrate how I recently improved web pages that let a user scan barcodes with a blue tooth barcode scanner. Big thanks to Declan Lynch for the help on the Client Side JavaScript solution. This also takes advantage of the undocumented XSP.fireEvent() method.

A little more information about this technique can be found here :


In XPages you can add an id to an event handler and call it from CSJS.

Ok let’s get this out of the way.  I’m going to talk about Client Side JavaScript and that’s WAY out of my comfort zone on a good day.  But I had a need to work with it and the amazing Declan Lynch came to the rescue.

I want to make a NotesIn9 about this when I can but as I’m crushed with work I just don’t know when that might be so here’s my attempt at blogging some technical information.  🙂

Today I had the need to use client side java script to trigger the existing event of an editbox control.

I didn’t want to run a function, I didn’t want to trigger a partial refresh directly, I wanted to trigger an event on a component from csjs.

<xp:inputText id=“myInputBox”  value=“#{viewScope.vsMyValue}”>

<xp:eventHandler id=“MyEvent” event=“onkeypress” submit=“true” refreshMode=“partial” refreshId=“#{javascript:compositeData.refreshTarget}”>





So that’s what the <xp:inputText> might look like.  The key to everything here is you can manually add an id to the <xp:eventHandler> and then target it!!

What I needed was the XSP.fireEvent


Worked like a charm.

XSP.fireEvent(evt, clientId, targetId, clientSideScriptName, submit, valmode, execId) Allows to trigger an event script

Note that this fireEvent MIGHT be unsupported.  It seems to be as of 2013 from this StackOverFlow question :

In this case the targetId is the name of the id I added to the event handler.

That’s pretty much all I know.  Seems to work great but I’ll know more tomorrow.  

I hope this might be helpful to someone.

Community Java Learning XPages XPages

Discussion on using PageControllers in XPages

WARNING:  This is a long one.  Enter if you dare.  

In the XPages Slack chat, which is free for anyone to join, hint hint.  Whenever I see people working together to solve an interesting problem I always try and suggest that someone blog it so the content and solution they’ve worked though gets a bigger audience. I’ll publish it myself if the person doesn’t have a blog. I don’t think I’m always successful but I try.  Anyway today is my turn to try and lead by example. I was typing up a long response to an email and thought – F this… I’ll just blog this for everyone.

Below is an email I got from a NotesIn9 Viewer (and friend) who is having some questions related to episode 182.  In that episode I tried to just do a quick take on how to do CRUD (Create, Read, Update, Delete) operations using Java and XPages.  I think one of the points of confusion was that I was more focused on the Java bits, and didn’t do a great job at hooking into the actual pageController for the “Project” XPage.  I didn’t want to use Jesse Gallagher’s awesome Frostillicus framework and have that dependency.  I ended up using a manual managed bean when I should have used Object Data Source.  I simply never thought of using Object Data for a page controller until I think it was Paul Withers that mentioned it in the Slack Chat.  doh!

Anyway here’s the last email he sent in this thread…

I never did figure out why faces-config was empty whenever I created a new database, but since I’m able to manually create the XML file, I got over it.

I must admit to being confused about how you did the data sources for NotesIn9-182. I see from what you wrote above that I can handle this by either importing Jesse’s framework or by using Object Data. But you indirectly also said that’s not how you did it for NotesIn9-182.

I’m looking at the Project XPage. The XPage doesn’t have a Data Source but computedField1 gets its value via Simple data binding with Data source set to “ProjectControl” and Bind to set to “currentProject.unique.

So how DID you set the value for computedField1? I guess it really doesn’t matter since I need to either use Jesse’s or Object Data, but this does make me curious.

And it turns out that creation order of the design elements seems to matter some, but in a Captain Obvious kind of way. For example, requires both and com.notesin9.tracker.Project and com.notesin9.tracker.Task. to be created first (at least in part) because controller.project uses all of them.

So if in the project page, I want to display the name of the person who created the project.

  • The name of the project creator is the property “creator” of the class “Project”
  • “Project” is imported by the class “project”.
  • “currentProject” is an object declared in the class “project”.
  • In faces-config or in Object Data, methods and properties in the object “project” are referenced by the Data Source name “ProjectControl”.
  • So the value of the computed field that displays the creator used ProjectControl as the data source from which currentProject.creator is retrieved.
  • Wow. As dumbed down as this is, this is still a lot.

Time for me to File.Application.New and reduce it to its bare essentials.

Thanks again for your help.

And my response is :

I think I’ve seen the blank faces-config thing before..  not sure…  I just now created a new database and went in and all it gave me was :

<?xml version="1.0" encoding="UTF-8"?>

Is that what you’re seeing? or is it totally blank?

It used to be more like this by default

  <!--AUTOGEN-START-BUILDER: Automatically generated by IBM Domino Designer. Do not modify.-->
  <!--AUTOGEN-END-BUILDER: End of automatically generated section-->

And then you’d add beans like this :

  <!--AUTOGEN-START-BUILDER: Automatically generated by IBM Domino Designer. Do not modify.-->
  <!--AUTOGEN-END-BUILDER: End of automatically generated section-->


I might not have full understood the last email.  The order does matter when it comes to Java.  The order of elements for the other stuff doesn’t really matter.  I could link an xpage to a page controller that didn’t yet exist if needed.  The XPage wouldn’t care because it doesn’t know about it from designer itself.

Ok… regarding the Project Page….

for every XPage these days I want to have a Java class acting as a “pageController”.  This lets me put almost all my logic in a nicely coded class and gets it off the XML of the XPage and all that “CDATA” crap.  There are just a lot of benefits to this approach.

In that show I choose to make a viewScoped managed bean in the faces config.  I did this because 1. I didn’t want the frostillicus dependency and 2. Stupidly I didn’t think of using object data.  Object data would have been better to use for the controller.

Because it’s a managed bean… there doesn’t need to be anything defined in the xpage dataSource… That’s what a managed bean is… you define it at faces-config and now it’s available anywhere in the application whenever you call it.  The XPages runtime will create it automatically – which is why managed beans require an empty constructor.  It’s not a bad thing to have managed beans…  and a great example of needing a managed bean might be for a shopping cart object… something that lives in sessionScope… so it has the longer life..  though technically a you could also manually put a cart object in sessionScope from a page Controller..  retrieve it when you want and get the same results…  like everything there’s multiple ways to arrive at the same destination.

So how did computedField1 get it’s value?   Let’s look.  

Here’s what it looks like in the main “pretty pane” : 


The dataSource is the managed bean.  Which holds a custom object called “currentProject”.  Which has a method to get the unique value.

So this screenshot translates to : 


And that would work if using SSJS.

But you can’t type “ProjectControl” into the dropdown.  That’s annoying and I’ve mentioned that to IBM recently in fact.  So you need to go to the Advanced Tab and choose Expression Language (EL) and just type it in there :


And in the source it will then render as this : 

<xp:text escape="true" id="computedField1"
value="#{ProjectControl.currentProject.unique}" styleClass="form-control">

Just a side note – since this value doesn’t change I probably should have set it to Compute on page Load….


Now regarding your bullet lists….

First remember what’s going on here…  We’re trying to get to at least some form of “MVC” which is “Model”, “View”, and “Controller”…  And honestly I don’t know all the technical purist definitions of this so here’s how I like to think of it when I work.

VIEW: The XPage is to display information to the user.  I guess this is the “View” but I’m not sure.  It’s responsible the UI and everything you display.  BUT ideally it’s NOT responsible for anything that requires “logic”. No heavy lifting. And it doesn’t talk directly to the data itself.  No binding to documents or views. (Of course there might be exceptions)  All that belongs in the “Controller”.  So ideally the XPage only talks to the Controller.

CONTROLLER: The controller is just a java class to hold any logic that the XPage needs and is also the gatekeeper between the xpage and the actual data. Any logic to show or hide content belongs here.  All this controller really is, at it’s core, is a viewScoped bean that’s specific to the XPage.  This bean could be created manually by adding it to faces-config – like I did in show 182.  But that probably isn’t the best way as you don’t want to make a faces-config entry for each bean if you have a ton of pages.  So as an alternative you can use Jesse Gallagher’s frostillicus framework – which is lovely – or on the page you can use the Object Data to create the controller Object right on the page.

<xe:objectData var="controller"
createObject="#{javascript:return new controller.demos();}"></xe:objectData>

So in that instance if I have a java class called “controller.demos” the Object data code will create the object and give it a variable called “controller” and I can now reference it anywhere on the page.  The variable can be anything of course.  Again, all this really seems to be, is a viewScoped managed bean.  By default, this object lives during the life of the page it’s created on.

MODEL: The Model, is the means to actually get to the data itself.  In the JavaCrud app from show 182 I had a java class for “Project” and “Task”.  These classes represent notes documents.  These objects get loaded into the pageController as needed.  Now I admit it seems confusing to have all these similar names.  “project.xsp” for the XPage.  “controller.project” for the page controller and “com.notesIn9.tracker.Project” for the model object.  yuck!  I don’t know a better way really.  There’s a little more flexibility using Object Data but Jesse’s framework requires the pageController to be the exact same name as the XPage itself.  Note that I always try to use lowercase for the controllers and Uppercase for the Model objects.

So why do all this?  as you say “Wow. As dumbed down as this is, this is still a lot.”  And you’re right. It is. But it’s so much better in the long run – though I’ll leave that discussion for a future post or show.  This is long enough now. haha

Hopefully that helps clear things up.  If not let me know.