In this show Greg Reeder, XPage developer and new contributor joins the show to talk some Java and how you might be able to use it to build a logging control for errors and messages.
This is the first of a 3 part series from Greg which I’m publishing all at once due to the length and complexity of the information.
In this show Greg Reeder, XPage developer returns for part 2 of his series to talk some Java programming and how you might be able to use it to build a logging control for errors and messages.
This is the second of a 3 part series from Greg which I’m publishing all at once due to the length and complexity of the information.
In this show Greg Reeder, XPage developer returns for part 2 of his series to talk some Java programming and how you might be able to use it to build a logging control for errors and messages.
This is the third of a 3 part series from Greg which I’m publishing all at once due to the length and complexity of the information.
In this show, Jesse Gallagher officially starts the NotesIn9 Hackathon with a great introduction on “custom renderers” in XPages. While this seems to be a really scary topic, Jesse explains it in a way that even I can grasp it.
In this show Jesse Gallagher returns to give us an introduction to this amazing Framework he’s created to try and improve the XPages coding experience.
I can’t say that I totally “get it” yet BUT it looks VERY interesting. I have so far taken the “controller” piece from the framework and I’m successfully using that in my applications and I’ll be featuring that on NotesIn9 very soon. It’s really improved how I create my applications.
This show beings my great experiment. I’ve wanted to do this for a couple of years actually. I’m going to ATTEMPT to start from scratch and build an XPages Application.
I’m going to assume that the viewer has little to no knowledge of Domino Development. I’ve gotten a bunch of emails from people brand new to the platform so the beginning shows are kinda geared for them. I’m really trying to start from square one.
When I get into the Application build – which won’t be till the 5th show I believe, I’m going to TRY and build a “typical” XPages application – Companies, contacts, Activities… stuff like that. But when I do get into the App build, It’s going to be built with a heavy preference for Java and Managed Beans. Why? Must I use Java to build this kind of application? Absolutely not. No Java needed. But I’m going to use it for 2 reasons:
1-People have been asking for this kind of information
2-This is how I might build an app in the day job so that’s what I’m going to do here.
So that’s why I’m using Java. It will also let me get into making a “business api” I hope.
I’m also going to use Bootstrap and the OpenNTF API. Basically any tool in the toolbox.
That’s the plan anyway.
P.S. In this show I meant to start with actually installing the designer software, but messed something up and didn’t want to redo it. I figure clicking on the installer isn’t that big a deal. So this show starts off after the initial install.
P.P.S If you’re a beginner and want further information and an alternate view point on starting XPages development, you might want to check out a video series from Paul Della-Nebbia on his blog.
Oh and there is one more thing….
Some episodes MIGHT contain some “bloopers” at the end.
In this show we finally start coding. Horaay! I’m going to create a form and a couple views to start setting up how the data for the applicaiton will work and then I’ll go right into some Java which will act as a bridge between our application and the data that gets stored into the database itself.
This show should be particularily good if you’re interested in starting to use Java with your XPages applications.
Note: This episode was filmed a couple weeks ago when I was watching the Philadaphila Eagles beat up on the New York Giants. The Eagles won 27 – 0! It was a good night. 
In this show I demonstrate how to setup and set using a Java “Page Controller”. This is a technique that Jesse Gallagher came up with and I absolutely love. Without a doubt it saved me a TON of work on a recent day job assignment. There’s a little effort involved in setting it up but it’s so worth it in the long run.
In this show I continue on to the goal of CRUD. CRUD stands for Create, Read, Update and Delete. By the end of this show we should be able to achieve all 4 actions against the Company document.
I’ve not done anything to really make this app look pretty yet. Honestly I’ve given the UI very little thought so far. I’m trying to just focus on the core functionality at the moment so the UI stuff doesn’t distract. I do want to better integrate Bootstrap to clean up the UI at some point when it makes sense.
Note: I’ve been pushing a bunch of these shows out quickly. I filmed them a while back in one evening. I believe I have one more small one then I’ll probably take a little break from this series as I have another personal XPages project that must be ready by Thanksgiving.
In this show XPages “Professor” and IBM Champion, Mr. Paul Withers returns for an in depth look at how to use the Java Debugger to step through the Java code in your XPages applications. In the beginning and end of the show he’ll also talk about OpenLog which was originally an AMAZING project from Julian Robichaux that Paul has enhanced for the XPages world.
This show finally sees a slightly different format that I’ve been wanting to do for a while. We did this demo via Gotomeeting so I was able to talk to Paul and ask some questions throughout the demo. I’m hoping this will be a benefit for certain topics and maybe even certain speakers – especially new ones that might not feel comfortable in doing a demo solo. So really there should be no more excuses.
Let me know what you think!
Thanks
Dave
This is one of those shows that I think is really important.
Today we welcome Eric McCormick, a new contributor and IBM Champion, to the show. Eric did a geat demo showing us how to get started using Java to make Servlets inside our XPages Applications. This opens a lot of doors to expose your data to applications outside of the Domino server.
Note: This show doesn’t have great audio. My headset stopped working for some reason and also Eric recorded the show in several takes I think. I tried to clean up what I could – hopefully it’s not a huge problem.
In this show I do an in depth demo of an XPages app that’s based on Java Code. I didn’t take time to build it from scratch in front of you, but I go over every line of code in the app.
The app lets you you Create, Read, Update, and Delete Project documents, and then add to each project an unlimited number of tasks.
It’s a long demo – but I first show the app, then go through all the Java code, and then finally the XPages code itself.
I hope this helps you put the pieces together to consider adding Java to your XPages toolbox.
Note: In the Demo, I do use the OpenNTF Domino API which makes life so much easier. It’s not required and in the near future I will try to produce a “cheatsheet” to help translate from the API to the lotus.domino classes.
In this show Eric McCormick returns to show us how to use SonarQube and Docker to help us improve our code.
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, controller.project.java requires both controller.base.java 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"?> <faces-config/>
Is that what you’re seeing? or is it totally blank?
It used to be more like this by default
<faces-config> <!--AUTOGEN-START-BUILDER: Automatically generated by IBM Domino Designer. Do not modify.--> <!--AUTOGEN-END-BUILDER: End of automatically generated section--> </faces-config>
And then you’d add beans like this :
<faces-config> <managed-bean> <managed-bean-name>ProjectControl</managed-bean-name> <managed-bean-class>controller.project</managed-bean-class> <managed-bean-scope>view</managed-bean-scope> </managed-bean> <!--AUTOGEN-START-BUILDER: Automatically generated by IBM Domino Designer. Do not modify.--> <!--AUTOGEN-END-BUILDER: End of automatically generated section--> </faces-config>
interesting…
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 :
ProjectControl.getCurrentProject().getUnique().
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"> </xp:text>
Just a side note – since this value doesn’t change I probably should have set it to Compute on page Load….
Anyway….
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.
<xp:this.data> <xe:objectData var="controller" createObject="#{javascript:return new controller.demos();}"></xe:objectData> </xp:this.data>
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.
Dave
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.
In this show I show you how I typically go about converting a Domino Document to a pure Java Object.
This is the big one! The last demo of my presentation at MWLUG 2016. In this show I’ll demonstrate how you can use something called a “Bitmask” and combine it with some Java code and the Apache Poi project to allow the user to create a custom Excel spreadsheet. The user will be able to choose any column they want from the data provided and save it to Excel. Users like that kind of stuff.
Wow! Major milestone here. I really don’t want to make too huge a deal of this at the moment but I do have to say thanks for all the contributors that helped the show get to 200 episodes. NotesIn9 has contributed 94 + hours of free tips and tricks to the community. Most importantly to me, 41 contributors have donated their time and talents to the show and I am so grateful for them helping out with my silly little corner of the Internet. I could never thank them enough.
I had many ideas for what to do with this show and in the end I decided to try and help a viewer who sent me an email. NotesIn9 was created to help others so to me it seems so very appropriate to mark this milestone with at least an attempt at helping others learn to code.
Learn. Code. Share.
In this show the amazing John Jardin returns with great information on how to get attachments sent to 3rd parties.
Since integration with other systems is becoming more and more critical you certainly want to be thinking about this.
