Categories
Java

NotesIn9 207: Send Attachments to 3rd parties

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.

Categories
Community Java XPages

NotesIn9 200: Access Server Databases From Code

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.

 

Categories
Java Notes In 9 Podcast XPages

NotesIn9 199: Bitmask, Enums and Creating Excel reports from XPages

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.

Categories
Java Notes In 9 Podcast XPages

NotesIn9 198: Convert a Document to a Java Object in XPages

In this show I show you how I typically go about converting a Domino Document to a pure Java Object.

 

Categories
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.

Categories
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, 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” : 

figure1

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 :

figure2

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

 

Categories
Java Other Tech

Notes In 9 : 189 Introduction to SonarQube with a side of Docker

In this show Eric McCormick returns to show us how to use SonarQube and Docker to help us improve our code.

Categories
Java Learning XPages XPages

NotesIn9 182: XPages and Java from Start to Finish

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.

 

ni9-182 Demo File.nsf

Categories
Java XPages

NotesIn9 173: Getting Started with Servlets

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.

Eric’s Blog

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.

Categories
Java Podcast XPages

NotesIn9 172: XPages Java Debugging

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