Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

CollabSphere 2019 - Preparing Your XPages Applications for a Changing Future

1,136 views

Published on

The XPages environment served us well for over a decade, but now we face complicated prospects for keeping our applications up-to-date and developing new ones. This session will discuss lessons learned from the process of abstracting a large production XPages application in-place, steps that can be taken with any scale of app today, and some of the options available to us.

Published in: Software
  • Be the first to comment

  • Be the first to like this

CollabSphere 2019 - Preparing Your XPages Applications for a Changing Future

  1. 1. Preparing Your XPages Applications for a Changing Future What next?
  2. 2. @Gidgerby — http://frostillic.us http://iksg.us — http://www.darwino.com Jesse Gallagher
  3. 3. • I don’t work for HCL • I don’t have any real inside information on their plans • The landscape could change – …it probably won’t change dramatically, though Disclaimer
  4. 4. About the world • XPages itself isn’t likely to go anywhere • Browsers, though, are going to keep moving About you • You’re an active XPages developer or otherwise responsible for current XPages apps • Your plan for these apps isn’t “leave Domino entirely” Some Assumptions
  5. 5. The Future of XPages?
  6. 6. The Future of XPages? • OpenNTF Domino API • Poi4XPages • SmartNSF • XPages Jakarta EE Support • JAX-RS • CDI • Bean Validation • Maven + Tycho • NSF ODP Tooling • Swiper • XPages Debug Toolbar • xockets.io • XPages SDK for Eclipse • JaCoCo
  7. 7. The Future of XPages?
  8. 8. Let’s Start Simpler
  9. 9. • Ditch SSJS • Use Source Control and Maven • Write less XSP markup • Use standard and ExtLib controls when possible • Don’t go too crazy with client JS • Learn Java 8 (and look at Jakarta EE 8) • Move complicated app code into an XPages Library (even when not yet shared) • Consider JAX-RS and client JS for new apps Short-Term Steps To Take
  10. 10. • This isn’t new advice • SSJS can’t be refactored or processed like Java • Binding the logic with the UI is a disaster • The way the language and Domino API interact leads to bad assumptions • It’s a product-specific language Ditch SSJS
  11. 11. • Even if you’re the only developer! • Source control is an invaluable safety net • GitFlow (and other techniques) let you work with releases, hotfixes, and features properly • And even if you’re not using plugins! • Set up a Jenkins server and have reliable, clean NTFs for every commit • NSF ODP Tooling: http://github.com/OpenNTF/org.openntf.nsfodp Use Source Control and Maven
  12. 12. • Every line is essentially technical debt • …and also increases the cognitive load in the app • Use stock core and ExtLib controls whenever possible • Form table, Dijit tab containers, Dijit content panes, and widget containers are personal favorites • Limit your use of HTML tags, and make them consistent when you do use them • Style (gingerly) with stylesheet files, not inline styles Write Less XSP Markup
  13. 13. • It’s hard not to at this point, unfortunately • Charts, fancy “view” tables, and other widgets are often best done this way • Consider using Dojo first, because it’s included anyway • When writing client JS, look into ES6+ constructs like classes • https://www.caniuse.com • If you have to support IE 11, then, uh… get another IT director, I guess Don’t Go Too Crazy With Client JS
  14. 14. • Java 8 is in 9.0.1FP8+ and is fully supported in FP10+ • Lambdas, try-with-resources, new collections methods, and new helper static methods • Check out Map#computeIfAbsent in particular • https://www.slideshare.net/JulianRobichaux/connect2017- dev1550-why-java-8-or-whats-a-lambda • Try building a Jakarta EE application to dip your toes in the water • https://frostillic.us/blog/posts/2019/1/17/122236e1b44e3de28525 8385008366f4 Learn Java 8 (And Look at Jakarta EE 8)
  15. 15. • The line where this is best is very fuzzy • It’ll definitely increase the complexity in the short term • However, it makes it easier to work with a large amount of Java code • Eclipse is your best bet, and IntelliJ sometimes works • VS Code, unfortunately, doesn’t work with Tycho projects • https://frostillic.us/blog/posts/2015/11/3/99CE7CC2CBC3C9DA 85257EF200408B6E Move complicated app code into an XPages Library
  16. 16. • Faces component references in code • Loose use of DominoDocument • Assumption of FacesContext existing • Subtle things like ICU and the “domino”-package StreamUtil • SelectItem is difficult Reduce Dependency on XSP-isms
  17. 17. • In this case, don’t even use XSP markup at all • Use SmartNSF or XPages Jakarta EE support to write REST APIs • Then use React, Stencil, or any other toolkit to write a client JS app • This eliminates immediate worries about XPages longevity, but is more complicated to learn and maintain (at first) Consider JAX-RS and Client JS for New Apps
  18. 18. Thank You! Q&A

×