XPages to Java EE, Part 11: Mixing MVC and an API 

By Jesse Gallagher | 2/16/19 1:10 PM | App Dev - XPages | Added by John Oldenburger

When we set up our MVC controller classes, we put the @Controller annotation at the class level, which tells the environment that the entire class is dedicated to running the UI. However, we don't necessarily always want to do that - JAX-RS is the way to build REST APIs, after all, and so we should also add JSON versions of our Person methods.

XPages to Java EE, Part 10: Data Storage 

By Jesse Gallagher | 2/15/19 1:00 PM | App Dev - XPages | Added by John Oldenburger

How you store your data in an application is a potentially-huge topic, which is one of the reasons I've pushed it off for a while. This is particularly the case because of the habits we learned over the years as Domino developers. One of the most grievous wounds Domino inflicted on us was an encouragement to always write directly to the data-storage implementation objects - forms and views for Notes client design or the lsxbe/lotus.domino classes for LotusScript and Java.

XPages to Java EE, Part 9: IDE Features Grab Bag 

By Jesse Gallagher | 2/13/19 11:58 AM | App Dev - XPages | Added by John Oldenburger

In today's post, I'm going to go over a handful of features that IDEs, particularly Eclipse, bring to the table to improve the development experience. Some of these aren't unique to EE development, but our use of Maven and standardized technology makes them better than their equivalents in XPages development.

XPages to Java EE, Part 8: IDE Server Integration 

By Jesse Gallagher | 2/12/19 11:37 AM | App Dev - XPages | Added by John Oldenburger

I said that the next post was going to be about authentication or databases, but I'm turning that into a filthy lie. Instead, we're going to take a bit of a detour to talk about a couple ways to let the IDE help you out in development. I'll be talking about Eclipse specifically, but I know that at least the paid version of IntelliJ IDEA has similar features. The first feature on the docket is having the IDE manage an app server for you.

XPages to Java EE, Part 7: MVC 

By Jesse Gallagher | 2/12/19 2:32 AM | App Dev - XPages | Added by John Oldenburger

I mentioned in the last post that the rest of this tutorial is going to involve making some technology choices that are less universal than the ones up until this point. While pretty much every new EE app is going to involve CDI and JAX-RS, things will start to diverge once you decide on how you're going to handle authentication, your UI, and your data storage. We're going to dip into the the second one of those today.

XPages to Java EE, Part 6: Dependencies 

By Jesse Gallagher | 2/1/19 2:45 AM | App Dev - XPages | Added by Oliver Busse

This is going to be a quick post, but I think it's useful to treat the topic of third-party dependencies on its own because of how much nicer it is with a Maven-based app than an NSF or OSGi plugin. Historically, we've handled dependencies primarily by downloading a Jar and either plunking it in jvm/lib/ext on the server, stashing it in a Java agent or script library, or importing it into the NSF as a Jar design element for XPages. With OSGi plugins, that remained the simplest way to do it too: just drop the Jar into the plugin and add it to the bundle classpath.

XPages to Java EE, Part 5: Web Pages 

By Jesse Gallagher | 1/24/19 12:23 PM | App Dev - XPages | Added by Oliver Busse

Once upon a time, web pages were easy: you'd write some HTML directly or, if you're fancy, use some Server Side Includes or PHP. Now, though, it's a rat's nest of decisions and stacks - fortunately for me, going into the pros and cons of each approach is beyond the scope of this series. Suffice it to say that Java EE can cover your needs whatever approach you take: it can do basic dynamic HTML generation, server-persisted frameworks like JSF, and work splendidly as a backend for a client JS app thanks to JAX-RS.

XPages to Java EE, Part 4: Application Servers 

By Jesse Gallagher | 1/23/19 6:15 PM | App Dev - XPages | Added by Oliver Busse

I mentioned in the terminology post that one of the new things to get used to in Java EE is the concept of a "Servlet Container" or "Application Server", and I think that this concept is worth a bit of going in to. In a general sense, we've been working with this concept for a good while now: Domino is an application server in several senses, and (for the most part) the NSFs are the applications it houses. It blurs the lines in a couple ways by virtue of NSFs also being data stores, but an XPages application is a pretty direct match for a .war file deployed to an application server, code-wise.

XPages to Java EE, Part 3: Hello, World 

By Jesse Gallagher | 1/22/19 2:40 AM | App Dev - XPages | Added by Oliver Busse

I expect that I'll have some more theory and explanation to get to in future posts, but I think it will be useful to run through a quick example project. Unlike with my XPages/OSGi examples, there won't be anything in this one that you wouldn't find in any old Java EE tutorial - indeed, I'll be piggybacking on some existing ones to speed things along.

XPages to Java EE, Part 2: Terminology 

By Jesse Gallagher | 1/18/19 1:36 PM | App Dev - XPages | Added by Oliver Busse

Much like with my earlier series, I think it'll be useful to take a minute to go over some of the terms that we'll need to know for dealing with Java EE, beyond just the many names of the platform. Additionally, I think it'll be useful to go over some of the things we specifically need to not know when it comes to non-OSGi development.

XPages to Java EE, Part 1: Overview 

By Jesse Gallagher | 1/18/19 3:08 AM | App Dev - XPages | Added by Oliver Busse

I've definitely come around to the idea that the future for Java with Domino involves Java/Jakarta EE. HCL apparently feels the same way, though what that "J2EE" bit on their slide means remains unspecified. Regardless, I think that it's important for the XPages community to at least dip our toes into JEE proper, and I plan to share some of my experiences with doing so.