Eureka! The Padawan's Guide to
    the Dark Side of XPages
          #uklugEureka




                         Presenter: Paul Withers
                         Company: Intec Systems Ltd
                         Twitter: @paulswithers

                         Presenter: Tim Tripcony
                         Company: GBS
                         Twitter @timtripcony
Agenda

• Introduction
• XPages Server Processing
• JVM and the NSF
• Memory Management
• JSF Lifecycle: Event Model
• JSF Lifecycle: Performance Smackdown
• Summary
• Bonus Material (*B1)
Paul Withers

• Senior Domino Developer, Intec Systems Ltd
• XPages Developer since 8.5.0
• IBM Champion
• Co-Host of The XCast
• XPages Extension Library Book
Tim Tripcony
• XMage, GBS

• IBM Champion

• XPages Extension Library Book
Why This Session?

• Nothing in life is to be feared, it is only to be understood. Now
  is the time to understand more, so that we may fear less.
                                                   Marie Curie

• A matter that becomes clear ceases to concern us.
                                              Friedrich Nietzsche

• Furious activity is no substitute for understanding.
                                                    H.H. Williams

• No. I am your father.
                                                      Darth Vader
Ex pectations

• You should:
  • Know what XPages are
  • Know that XPages run on a Domino server
  • Know Computed Field, Edit Box and Repeat controls
• You don't need to:
  • Know Java
  • Have a thorough knowledge of JSF
  • Have knowledge of dataContexts, managed beans,
     PhaseListeners or VariableResolvers
Agenda

• Introduction
• XPages Server Processing
• JVM and the NSF
• Memory Management
• JSF Lifecycle: Event Model
• JSF Lifecycle: Performance Smackdown
• Summary
• Bonus Material
XPages and Domino Server




           Java Virtual Machine



          XSP Command Manager


           Domino HTTP Server
When An XPage Is Served...(*B3)

• Can HTTP Server resolve the URL to an NSF?
  • HTTP 404 Error

• Does user have access to NSF?
  • HTTP Authentication Page

• Can HTTP Server find resource in the NSF?
  • HTTP 404 Error

• Does the signer have access to run XPages? (*B3)
  • HTTP 403 Error

• Are there SSJS errors?
  • XSP Command Manager takes over (*B1-B2)
• Return XPage
Agenda

• Introduction
• XPages Server Processing
• JVM and the NSF
• Memory Management
• JSF Lifecycle: Event Model
• JSF Lifecycle: Performance Smackdown
• Summary
• Bonus Material
Java Virtual Machine Means...

• Each NSF is a separate Java application
• applicationScope, sessionScope etc. is per NSF (*B4)
  • Browser session, NOT user session
  • Setting sessionScope in Db1.nsf does NOT set
     sessionScope in Db2.nsf

• sessionScope is ONLY within JVM – not cleared by HTTP
  logout
JAVA Virtual Machine

• XPages → Java classes → Java bytecode (*B5-B7)
• Each control is a Java class
• Extensions are pre-packaged Java classes
  • Define properties (what can be customised)
  • Define renderers (what is printed)

• SSJS code is String passed to Java method
• Java code prints HTML to browser
XPages Languages

• Literal values
  • Strings, booleans etc.
• SSJS
  • #{javascript:document1.getItemValueString(“FirstName”)}
• Expression Language (*B8)
  • #{VARIABLE.PROPERTY}
  • #{document1.FirstName}
  • #{database.title} = #{javascript:database.getTitle()}
• Custom
  • Any of the above combined
  • “Database title is #{database.title}”
Language Hypotheses

• Fewer controls should perform better (*B9)
• Literal strings should perform best. Expression Language
  should perform better than Server-Side JavaScript

• Combining languages should allow:
  • Fewer controls to be used
  • Literal Strings and Expression Language to be used
      instead of SSJS
  •   So better performance
Agenda

• Introduction
• XPages Server Processing
• JVM and the NSF
• Memory Management
• JSF Lifecycle: Event Model
• JSF Lifecycle: Performance Smackdown
• Summary
• Bonus Material
JSF and Serialization

• HTTP is state-less
• JSF keeps state-full server representation of UI
  (component tree or view)

• Objects stored in component tree must be serializable
  (persist between requests)
  • Domino objects recycled after each request
  • Datasources are recycle-safe

• Objects stored in ViewScope etc must also be
  serializable
Server-Side Map
Persistence options

• Component tree (map of XPage on server)
  • either held in memory of JVM
  • or serialized to disk

• xsp.persistence.XXX properties
• See persistence tab of new xsp.properties editor
• Package Explorer → WebContentWEB-
  INFxsp.properties
Persistence Tab
Demo
Persistence Summary

• Keep Pages in Memory
  • Remembering, remembering, remembering
  • xsp.persistence.mode=basic
  • Best for...quick retrieval, few users

• Keep Pages on Disk
  • Writing...next? You want it again? Reading
  • xsp.persistence.mode=file
  • Best for...lots of users, but slower retrieval

• Keep Only The Current Page In Memory
  • Remembering, remembering, remembering
  • Oh, new page? Writing...and now
  • Remembering, remembering, remembering
  • xsp.persistence.mode=fileex
  • Best for...lots of users, quick retrieval of current page
Persistence Summary (*B11-13)

• Gzip Persisted Files
  • xsp.persistence.file.gzip (default=false)
  • default=false
  • Writing...next? You want it again? Reading

• Persist Files Asynchronously
  • xsp.persistence.file.async (default=true)
  • Server busy, remembering. Next? (Writing, writing)
• Maximum Pages...
  • xsp.persistence.tree.maxviews (*B10)
  • Remembering, remembering, remembering
  • xsp.persistence.file.maxviews
  • Writing, retrieving, writing, writing
Agenda

• Introduction

• XPages Server Processing

• JVM and the NSF

• Memory Management

• JSF Lifecycle: Event Model
• JSF Lifecycle: Performance Smackdown

• Summary

• Bonus Material
JSF LifeCycle
Six Phases

• Restore View
  • JSF component tree retrieved

• Apply Request Values
  • this.setSubmittedValue(passedValue) run
  • Any event logic run if immediate=“true”

• Process Validation
  • Any converters applied
  • Any validators applied
Six Phases

• Update Model Values
  • this.setValue(this.getSubmittedValue());
  • this.setSubmittedValue(null)

• Invoke Application
  • Any event logic run

• Render Response
  • HTML rendered and state saved
  • Only event that runs during page load
PhaseListener

• Must implement javax.faces.event.PhaseListener
  • Or extend a Java class that implements it
    • ExamplePhaseListener extends AbstractPhaseListener, which
       implements javax.faces.event.PhaseListener

• Allows us to track JSF lifecycle phases
• Java class plus reference in WebContentWEB-
  INFfaces-config.xml
Demo
Basic

• Validation fails
  •   beforeRestoreView
  •   afterRestoreView
  •   beforeApplyRequestValues
  •   afterApplyRequestValues
  •   beforeProcessValidations
  •   beforeRenderResponse
  •   afterRenderResponse

• Event logic not run
No Validation

• Conversion still honoured
  • If failed, skips from ProcessValidations to RenderResponse
  • Event Logic not run

• If no conversion errors, all phases run
• Values passed from submittedValue to value
• Component tree updated
im mediate="true"

• Validation fails
  •   beforeRestoreView
  •   afterRestoreView
  •   beforeApplyRequestValues
  •   afterApplyRequestValues
  •   beforeRenderResponse
  •   afterRenderResponse

• Event logic run in ApplyRequestValues phase
• Component value never goes past submittedValue
• Component tree not updated
Custom Validator (SSJS)

• Runs AFTER Apply Request Values
• Runs BEFORE Update Model Values
  • submittedValue property set
  • value property still NULL (or last stored value)

• Use validator property of control
• Check getSubmittedValue()
• Post error with facesContext.addMessage()
• Abort with this.setValid(false)
Custom Validator (Java)

• Runs at same time as any other validator
• Use xp:validator, child of validators property of control



• validatorId property maps to validator-id in faces-config.xml



• validator-class maps to Java class
Custom Validator (Java Class)

• Use Java class implementing Validator
  • javax.faces.validator.Validator

• validate(FacesContext,UIComponent,Object) method
  performs validation, returns void

• Post error using throw ValidatorException
• Third argument is submittedValue – String
• ValidatorException takes FacesMessage
  • javax.faces.application.FacesMessage
JSF Lifecycle

• Now you understand validation and JSF lifecycle
• But validation prevents SSJS running
• So how can you show / hide buttons based on this
• *B14
Agenda

• Introduction

• XPages Server Processing

• JVM and the NSF

• Memory Management

• JSF Lifecycle: Event Model
• JSF Lifecycle: Performance Smackdown

• Summary

• Bonus Material
What Are We Testing?

• Computed Field control with value property computed
• Two Edit Box controls with rendered property
  computed

• For each scenario:
  • On Page Load – how many calls
  • On Partial Refresh – how many calls (*B15)
What Are The Scenarios?

• Compute on Page Load (Loaded)
• Compute Dynamically (Runtime)
• Theme
• dataContexts
  • “Global variables”
  • Scoped to XPage, Custom Control, Panel
  • Referenced via EL – #{var1}

• execMode=“partial”
  • Runs over only part of component tree
Demo
Smackdown Results

• Loaded makes fewer calls
• Theme cannot override loaded (*B16)
• Runtime and theme makes same calls
• dataContext makes fewer calls (*B17)
• execMode=“partial” improves performance
  • IMPORTANT: Define id to execute lifecycle on
      EventHandler – All Properties
  •   Know what you're processing and what you're refreshing
      (*B18)
Agenda

• Introduction

• XPages Server Processing

• JVM and the NSF

• Memory Management
• JSF Lifecycle: Event Model
• JSF Lifecycle: Performance Smackdown

• Summary

• Bonus Material
Summary

• Scoped variables not cleared by ?logout
• Combining controls improves performance – big takeaway
• Persistence options can optimise application
• JSF lifecycle affects event processing
• loaded and dataContexts (for rendered) offer benefits
• execMode improves performance – huge takeaway
• But things get REALLY interesting when you look at
  performance of different languages for a rendered property in
  our repeat... (*B19-B20) – massive takeaway
Statistics – Combining Controls
Statistics – Lifecycle Sm ackdown
Thank You



• Paul Withers, Intec Systems Ltd
• Email: pwithers@intec.co.uk
• Twitter: paulswithers
• Blog: http://www.intec.co.uk/blog

• Tim Tripcony, GBS
• Email:
• Twitter: timtripcony
• Blog: http://timtripcony.com
          Please complete your evaluations
          and check out the 20 bonus slides
Agenda

• Introduction

• XPages Server Processing

• JVM and the NSF

• Memory Management
• JSF Lifecycle: Event Model
• JSF Lifecycle: Performance Smackdown

• Summary

• Bonus Material
B1 - HTTP Error 500 Reasons

• No server / custom error page defined
  • Falls back to $$ReturnGeneralError page, if available

• Missing Extension Library or other library on server
• java.lang.NoClassDefFoundError
• java.lang.securityException
• Check <domino>dataIBM_TECHNICAL_
  SUPPORTxpages_exc_ServerName_yyyy_
  MM_dd@hh_mm_ss.log
B2 – Resolving HTTP 500 Errors

• XPages Log File Reader from OpenNTF allows you to view
   server-based log files

• If this points to a Java class you've added to the database,
   make sure it hasn't “fallen out” of the Build Path

• If it's in the Build Path, is it trying to write to the file system.
   Could be prevented by java.policy security settings
B3 – XPiNC Caveats

• Server-based NSFs need a local XSP Command
  Manager etc.

• Authentication is via Notes logon on local PC
• Signer access is managed via ECL on local PC
• XPages Extensions, Java packages must be deployed
  locally

• Logging accessible from Help → Support → View Log
  on local PC
B4 – “ServerScope”

• XSP Starter Kit contains an example of managed
  beans that can be scoped to the server

• Good for multi-NSF applications
• Instead of managed bean server-scoped variables
  could be a Map set / got from OSGi VariableResolver
  • Application-based / server-based VariableResolvers
    are processed for EVERY variable referenced in
    XPages applications
  • Includes e.g. context, sessionAsSigner, database
  • Also includes var attributes of data, dataContexts
    etc, e.g. document1
B5 – XPages               Java Bytecode

• Editing is done in XPage / Custom Control design elements
• Build process (B5) creates .java
  files, visible in Package Explorer
B6 XPages              Java Bytecode

• These are compiled down to
  .class files, which are only visible
  in Project Explorer view
  • Window → Show Eclipse Views → Other
  • Start typing “Proj” and select Project Explorer
  • Customize the view, clear all filters
     and click OK
  • Right-click the pane to load contents
• Java class files are visible under
  WebContent  WEB-INF  classes

• Includes custom Java classes,
  XPages, Custom Controls
B7 – Manual Build
• Build Automatically
  • Builds any NSF when opened in Designer
  • Builds any open NSF (even in “hidden” Working Sets)
      when any design element is saved
  •   Has “broken” live applications when developer opened an
      NSF in Designer just to look at design and did not have
      access to run XPages code on the server
                           Switch it off!!

• When opening an NSF in Designer
  • An initial build is required to create local Java files
  • If no initial build has been done and a design element is
       changed, the first build just does an incremental build
        If you open an NSF in Designer and make a change,
      you need to build TWICE to see changes in the browser
B8 – Language Caveat

• Expression Language (on its own or within Custom language)
  can only be used in component attributes
  • Value property
  • Rendered property
  • Loaded property
• It cannot be used in eventHandlers
  • In Client you need to use
     alert(“#{javascript:database.getTitle()}”) instead of
     alert(“#{database.title}”)
B9 – Controls Investigation

• Look at the following pages under Bonus
• HTML vs XSP
  • “Pass-thru HTML” on an XPage still creates a control in the
     Java code

• Dojo Slider
• Ext Lib Slider
  • Ext Lib controls exist to make it easier for developers
  • They do not exist to enhance server-performance per se
  • But some Ext Lib controls lazy-load functionality
B10 – Persistence: Save to Disk

• xsp.persistence.tree.maxviews only applies when
  xsp.persistence.mode=basic

• Save to disk defaults to server temp directory, e.g.
  C:WindowsTempnotes270C3Exspstate2D8YWSWLP34

• Ensure relevant drive has enough space for scalability
• Default folder can be overridden using
  xsp.persistence.dir.xspstate

• Similar options for file uploads and attachments
B11 – Page persistence m ode

• xsp.persistence.viewstate=fulltree
  • Default option, whole component tree persisted
• xsp.persistence.viewstate=nostate
  • No component tree is stored, similar to
     xsp.session.transient=true

• xsp.persistence.viewstate=delta
  • Valid if pages stored in memory
  • Only stores changes since page first loaded
• xsp.persistence.viewstate=deltaex
  • Valid if multiple pages stored in memory
  • Stores full component tree for current page, deltas for
     others
B12 – x sp.session.transient

• xsp.session.transient=“false”
  • XPage becomes stateless
    • Default VALUES overridden between requests
    • Default STATES not overridden
• State not persisted
  • NOT “Go to next page” from current
  • INSTEAD “Go to next page” from default
  • NOT “Toggle show detail” from previous state
  • INSTEAD “Toggle show detail” from default
• Values persisted
• Great for large, read-only pages – no storage
• Need to build your own “relative” functionality
B13 – x sp.session.transient

• To see it in action, use the Teamroom database
• Check out normal dataView functionality
  • Expand All / Collapse All, Sorting etc toggles
  • Filter functionality works
  • Categories can be expanded
  • Detail can be expanded
• Set xsp.session.transient=true and build the app
• Check out dataView functionality now
  • Sorting doesn't toggle, just switches relative to default
  • Filter functionality doesn't work
  • Categories cannot be expanded
  • Detail can still be expanded, but only because dataView
     has detailsOnClient=true
B14 – Manipulating JSF Lifecycle

• See Bonus – Check Values / Submit
• Scenario
  • You want to display a button that says “Check
      Values” until all values are completed
  •   Then you want to display a “Save” button
  •   But if the user then removes the value from a
      required field, you want to display “Check Values”
      button

• RenderResponse always runs, so do the checks
 in the rendered property
B15 – Computing Refresh ID

• refreshId property can be computed
• How is this calculated during the JSF lifecycle?
• Bonus – Computed refreshId tests this
• The refreshId gets calculated during the
  renderResponse phase
B16 – Themes and Loaded

• Bonus – Theme Failing page in sample database
  • Themes cannot override a property that is Computed on
    Page Load

• Bonus – Theme Failing Repeat
  • Themes can set most properties on a control
  • E.g. value property of a repeat control
  • Required at page load time to create component tree
B17 – dataContex ts for value

• dataContexts can offer benefits for rendered property
• How do they perform when used for value property?
• Bonus – dataContext for Value demonstrates this
• Even though dataContext is overridden by theme, it is
  calculated several times during the lifecycle
B18 – ex ecMode Goes Wrong

• execMode and execId are very powerful
• Be carefuly about execId and refreshId
• Bonus – execMode demonstrates this
• execId defines which control values get passed to
  component tree

• refreshId defines which area gets updated on browser
• If refreshId is larger than execId, controls outside
  execId will lose their values
B19 - Repeats Revisited

• See Bonus – Language Performance + Rendered
  • rendered property set for each of 50000 rows
  • rendered property set in different ways

• SSJS in Script Library performs worst
• SL much worse on partial refresh
• VariableResolver best for performance
  • Deprecated in JSF 2.0 for ELResolver
• VariableResolver in OSGi plugin best for performance
  and reusability (check out XSP Starter Kit)

• dataContext next best, but only reusable within page
B20 – Comparisons




    If you're separating business logic from
       presentation, Java is the way to go

Eureka Moment UKLUG

  • 1.
    Eureka! The Padawan'sGuide to the Dark Side of XPages #uklugEureka Presenter: Paul Withers Company: Intec Systems Ltd Twitter: @paulswithers Presenter: Tim Tripcony Company: GBS Twitter @timtripcony
  • 2.
    Agenda • Introduction • XPagesServer Processing • JVM and the NSF • Memory Management • JSF Lifecycle: Event Model • JSF Lifecycle: Performance Smackdown • Summary • Bonus Material (*B1)
  • 3.
    Paul Withers • SeniorDomino Developer, Intec Systems Ltd • XPages Developer since 8.5.0 • IBM Champion • Co-Host of The XCast • XPages Extension Library Book
  • 4.
    Tim Tripcony • XMage,GBS • IBM Champion • XPages Extension Library Book
  • 5.
    Why This Session? •Nothing in life is to be feared, it is only to be understood. Now is the time to understand more, so that we may fear less. Marie Curie • A matter that becomes clear ceases to concern us. Friedrich Nietzsche • Furious activity is no substitute for understanding. H.H. Williams • No. I am your father. Darth Vader
  • 6.
    Ex pectations • Youshould: • Know what XPages are • Know that XPages run on a Domino server • Know Computed Field, Edit Box and Repeat controls • You don't need to: • Know Java • Have a thorough knowledge of JSF • Have knowledge of dataContexts, managed beans, PhaseListeners or VariableResolvers
  • 7.
    Agenda • Introduction • XPagesServer Processing • JVM and the NSF • Memory Management • JSF Lifecycle: Event Model • JSF Lifecycle: Performance Smackdown • Summary • Bonus Material
  • 8.
    XPages and DominoServer Java Virtual Machine XSP Command Manager Domino HTTP Server
  • 9.
    When An XPageIs Served...(*B3) • Can HTTP Server resolve the URL to an NSF? • HTTP 404 Error • Does user have access to NSF? • HTTP Authentication Page • Can HTTP Server find resource in the NSF? • HTTP 404 Error • Does the signer have access to run XPages? (*B3) • HTTP 403 Error • Are there SSJS errors? • XSP Command Manager takes over (*B1-B2) • Return XPage
  • 10.
    Agenda • Introduction • XPagesServer Processing • JVM and the NSF • Memory Management • JSF Lifecycle: Event Model • JSF Lifecycle: Performance Smackdown • Summary • Bonus Material
  • 11.
    Java Virtual MachineMeans... • Each NSF is a separate Java application • applicationScope, sessionScope etc. is per NSF (*B4) • Browser session, NOT user session • Setting sessionScope in Db1.nsf does NOT set sessionScope in Db2.nsf • sessionScope is ONLY within JVM – not cleared by HTTP logout
  • 12.
    JAVA Virtual Machine •XPages → Java classes → Java bytecode (*B5-B7) • Each control is a Java class • Extensions are pre-packaged Java classes • Define properties (what can be customised) • Define renderers (what is printed) • SSJS code is String passed to Java method • Java code prints HTML to browser
  • 13.
    XPages Languages • Literalvalues • Strings, booleans etc. • SSJS • #{javascript:document1.getItemValueString(“FirstName”)} • Expression Language (*B8) • #{VARIABLE.PROPERTY} • #{document1.FirstName} • #{database.title} = #{javascript:database.getTitle()} • Custom • Any of the above combined • “Database title is #{database.title}”
  • 14.
    Language Hypotheses • Fewercontrols should perform better (*B9) • Literal strings should perform best. Expression Language should perform better than Server-Side JavaScript • Combining languages should allow: • Fewer controls to be used • Literal Strings and Expression Language to be used instead of SSJS • So better performance
  • 15.
    Agenda • Introduction • XPagesServer Processing • JVM and the NSF • Memory Management • JSF Lifecycle: Event Model • JSF Lifecycle: Performance Smackdown • Summary • Bonus Material
  • 16.
    JSF and Serialization •HTTP is state-less • JSF keeps state-full server representation of UI (component tree or view) • Objects stored in component tree must be serializable (persist between requests) • Domino objects recycled after each request • Datasources are recycle-safe • Objects stored in ViewScope etc must also be serializable
  • 17.
  • 18.
    Persistence options • Componenttree (map of XPage on server) • either held in memory of JVM • or serialized to disk • xsp.persistence.XXX properties • See persistence tab of new xsp.properties editor • Package Explorer → WebContentWEB- INFxsp.properties
  • 19.
  • 20.
  • 21.
    Persistence Summary • KeepPages in Memory • Remembering, remembering, remembering • xsp.persistence.mode=basic • Best for...quick retrieval, few users • Keep Pages on Disk • Writing...next? You want it again? Reading • xsp.persistence.mode=file • Best for...lots of users, but slower retrieval • Keep Only The Current Page In Memory • Remembering, remembering, remembering • Oh, new page? Writing...and now • Remembering, remembering, remembering • xsp.persistence.mode=fileex • Best for...lots of users, quick retrieval of current page
  • 22.
    Persistence Summary (*B11-13) •Gzip Persisted Files • xsp.persistence.file.gzip (default=false) • default=false • Writing...next? You want it again? Reading • Persist Files Asynchronously • xsp.persistence.file.async (default=true) • Server busy, remembering. Next? (Writing, writing) • Maximum Pages... • xsp.persistence.tree.maxviews (*B10) • Remembering, remembering, remembering • xsp.persistence.file.maxviews • Writing, retrieving, writing, writing
  • 23.
    Agenda • Introduction • XPagesServer Processing • JVM and the NSF • Memory Management • JSF Lifecycle: Event Model • JSF Lifecycle: Performance Smackdown • Summary • Bonus Material
  • 24.
  • 25.
    Six Phases • RestoreView • JSF component tree retrieved • Apply Request Values • this.setSubmittedValue(passedValue) run • Any event logic run if immediate=“true” • Process Validation • Any converters applied • Any validators applied
  • 26.
    Six Phases • UpdateModel Values • this.setValue(this.getSubmittedValue()); • this.setSubmittedValue(null) • Invoke Application • Any event logic run • Render Response • HTML rendered and state saved • Only event that runs during page load
  • 27.
    PhaseListener • Must implementjavax.faces.event.PhaseListener • Or extend a Java class that implements it • ExamplePhaseListener extends AbstractPhaseListener, which implements javax.faces.event.PhaseListener • Allows us to track JSF lifecycle phases • Java class plus reference in WebContentWEB- INFfaces-config.xml
  • 28.
  • 29.
    Basic • Validation fails • beforeRestoreView • afterRestoreView • beforeApplyRequestValues • afterApplyRequestValues • beforeProcessValidations • beforeRenderResponse • afterRenderResponse • Event logic not run
  • 30.
    No Validation • Conversionstill honoured • If failed, skips from ProcessValidations to RenderResponse • Event Logic not run • If no conversion errors, all phases run • Values passed from submittedValue to value • Component tree updated
  • 31.
    im mediate="true" • Validationfails • beforeRestoreView • afterRestoreView • beforeApplyRequestValues • afterApplyRequestValues • beforeRenderResponse • afterRenderResponse • Event logic run in ApplyRequestValues phase • Component value never goes past submittedValue • Component tree not updated
  • 32.
    Custom Validator (SSJS) •Runs AFTER Apply Request Values • Runs BEFORE Update Model Values • submittedValue property set • value property still NULL (or last stored value) • Use validator property of control • Check getSubmittedValue() • Post error with facesContext.addMessage() • Abort with this.setValid(false)
  • 33.
    Custom Validator (Java) •Runs at same time as any other validator • Use xp:validator, child of validators property of control • validatorId property maps to validator-id in faces-config.xml • validator-class maps to Java class
  • 34.
    Custom Validator (JavaClass) • Use Java class implementing Validator • javax.faces.validator.Validator • validate(FacesContext,UIComponent,Object) method performs validation, returns void • Post error using throw ValidatorException • Third argument is submittedValue – String • ValidatorException takes FacesMessage • javax.faces.application.FacesMessage
  • 35.
    JSF Lifecycle • Nowyou understand validation and JSF lifecycle • But validation prevents SSJS running • So how can you show / hide buttons based on this • *B14
  • 36.
    Agenda • Introduction • XPagesServer Processing • JVM and the NSF • Memory Management • JSF Lifecycle: Event Model • JSF Lifecycle: Performance Smackdown • Summary • Bonus Material
  • 37.
    What Are WeTesting? • Computed Field control with value property computed • Two Edit Box controls with rendered property computed • For each scenario: • On Page Load – how many calls • On Partial Refresh – how many calls (*B15)
  • 38.
    What Are TheScenarios? • Compute on Page Load (Loaded) • Compute Dynamically (Runtime) • Theme • dataContexts • “Global variables” • Scoped to XPage, Custom Control, Panel • Referenced via EL – #{var1} • execMode=“partial” • Runs over only part of component tree
  • 39.
  • 40.
    Smackdown Results • Loadedmakes fewer calls • Theme cannot override loaded (*B16) • Runtime and theme makes same calls • dataContext makes fewer calls (*B17) • execMode=“partial” improves performance • IMPORTANT: Define id to execute lifecycle on EventHandler – All Properties • Know what you're processing and what you're refreshing (*B18)
  • 41.
    Agenda • Introduction • XPagesServer Processing • JVM and the NSF • Memory Management • JSF Lifecycle: Event Model • JSF Lifecycle: Performance Smackdown • Summary • Bonus Material
  • 42.
    Summary • Scoped variablesnot cleared by ?logout • Combining controls improves performance – big takeaway • Persistence options can optimise application • JSF lifecycle affects event processing • loaded and dataContexts (for rendered) offer benefits • execMode improves performance – huge takeaway • But things get REALLY interesting when you look at performance of different languages for a rendered property in our repeat... (*B19-B20) – massive takeaway
  • 43.
  • 44.
  • 45.
    Thank You • PaulWithers, Intec Systems Ltd • Email: pwithers@intec.co.uk • Twitter: paulswithers • Blog: http://www.intec.co.uk/blog • Tim Tripcony, GBS • Email: • Twitter: timtripcony • Blog: http://timtripcony.com Please complete your evaluations and check out the 20 bonus slides
  • 46.
    Agenda • Introduction • XPagesServer Processing • JVM and the NSF • Memory Management • JSF Lifecycle: Event Model • JSF Lifecycle: Performance Smackdown • Summary • Bonus Material
  • 47.
    B1 - HTTPError 500 Reasons • No server / custom error page defined • Falls back to $$ReturnGeneralError page, if available • Missing Extension Library or other library on server • java.lang.NoClassDefFoundError • java.lang.securityException • Check <domino>dataIBM_TECHNICAL_ SUPPORTxpages_exc_ServerName_yyyy_ MM_dd@hh_mm_ss.log
  • 48.
    B2 – ResolvingHTTP 500 Errors • XPages Log File Reader from OpenNTF allows you to view server-based log files • If this points to a Java class you've added to the database, make sure it hasn't “fallen out” of the Build Path • If it's in the Build Path, is it trying to write to the file system. Could be prevented by java.policy security settings
  • 49.
    B3 – XPiNCCaveats • Server-based NSFs need a local XSP Command Manager etc. • Authentication is via Notes logon on local PC • Signer access is managed via ECL on local PC • XPages Extensions, Java packages must be deployed locally • Logging accessible from Help → Support → View Log on local PC
  • 50.
    B4 – “ServerScope” •XSP Starter Kit contains an example of managed beans that can be scoped to the server • Good for multi-NSF applications • Instead of managed bean server-scoped variables could be a Map set / got from OSGi VariableResolver • Application-based / server-based VariableResolvers are processed for EVERY variable referenced in XPages applications • Includes e.g. context, sessionAsSigner, database • Also includes var attributes of data, dataContexts etc, e.g. document1
  • 51.
    B5 – XPages Java Bytecode • Editing is done in XPage / Custom Control design elements • Build process (B5) creates .java files, visible in Package Explorer
  • 52.
    B6 XPages Java Bytecode • These are compiled down to .class files, which are only visible in Project Explorer view • Window → Show Eclipse Views → Other • Start typing “Proj” and select Project Explorer • Customize the view, clear all filters and click OK • Right-click the pane to load contents • Java class files are visible under WebContent WEB-INF classes • Includes custom Java classes, XPages, Custom Controls
  • 53.
    B7 – ManualBuild • Build Automatically • Builds any NSF when opened in Designer • Builds any open NSF (even in “hidden” Working Sets) when any design element is saved • Has “broken” live applications when developer opened an NSF in Designer just to look at design and did not have access to run XPages code on the server Switch it off!! • When opening an NSF in Designer • An initial build is required to create local Java files • If no initial build has been done and a design element is changed, the first build just does an incremental build If you open an NSF in Designer and make a change, you need to build TWICE to see changes in the browser
  • 54.
    B8 – LanguageCaveat • Expression Language (on its own or within Custom language) can only be used in component attributes • Value property • Rendered property • Loaded property • It cannot be used in eventHandlers • In Client you need to use alert(“#{javascript:database.getTitle()}”) instead of alert(“#{database.title}”)
  • 55.
    B9 – ControlsInvestigation • Look at the following pages under Bonus • HTML vs XSP • “Pass-thru HTML” on an XPage still creates a control in the Java code • Dojo Slider • Ext Lib Slider • Ext Lib controls exist to make it easier for developers • They do not exist to enhance server-performance per se • But some Ext Lib controls lazy-load functionality
  • 56.
    B10 – Persistence:Save to Disk • xsp.persistence.tree.maxviews only applies when xsp.persistence.mode=basic • Save to disk defaults to server temp directory, e.g. C:WindowsTempnotes270C3Exspstate2D8YWSWLP34 • Ensure relevant drive has enough space for scalability • Default folder can be overridden using xsp.persistence.dir.xspstate • Similar options for file uploads and attachments
  • 57.
    B11 – Pagepersistence m ode • xsp.persistence.viewstate=fulltree • Default option, whole component tree persisted • xsp.persistence.viewstate=nostate • No component tree is stored, similar to xsp.session.transient=true • xsp.persistence.viewstate=delta • Valid if pages stored in memory • Only stores changes since page first loaded • xsp.persistence.viewstate=deltaex • Valid if multiple pages stored in memory • Stores full component tree for current page, deltas for others
  • 58.
    B12 – xsp.session.transient • xsp.session.transient=“false” • XPage becomes stateless • Default VALUES overridden between requests • Default STATES not overridden • State not persisted • NOT “Go to next page” from current • INSTEAD “Go to next page” from default • NOT “Toggle show detail” from previous state • INSTEAD “Toggle show detail” from default • Values persisted • Great for large, read-only pages – no storage • Need to build your own “relative” functionality
  • 59.
    B13 – xsp.session.transient • To see it in action, use the Teamroom database • Check out normal dataView functionality • Expand All / Collapse All, Sorting etc toggles • Filter functionality works • Categories can be expanded • Detail can be expanded • Set xsp.session.transient=true and build the app • Check out dataView functionality now • Sorting doesn't toggle, just switches relative to default • Filter functionality doesn't work • Categories cannot be expanded • Detail can still be expanded, but only because dataView has detailsOnClient=true
  • 60.
    B14 – ManipulatingJSF Lifecycle • See Bonus – Check Values / Submit • Scenario • You want to display a button that says “Check Values” until all values are completed • Then you want to display a “Save” button • But if the user then removes the value from a required field, you want to display “Check Values” button • RenderResponse always runs, so do the checks in the rendered property
  • 61.
    B15 – ComputingRefresh ID • refreshId property can be computed • How is this calculated during the JSF lifecycle? • Bonus – Computed refreshId tests this • The refreshId gets calculated during the renderResponse phase
  • 62.
    B16 – Themesand Loaded • Bonus – Theme Failing page in sample database • Themes cannot override a property that is Computed on Page Load • Bonus – Theme Failing Repeat • Themes can set most properties on a control • E.g. value property of a repeat control • Required at page load time to create component tree
  • 63.
    B17 – dataContexts for value • dataContexts can offer benefits for rendered property • How do they perform when used for value property? • Bonus – dataContext for Value demonstrates this • Even though dataContext is overridden by theme, it is calculated several times during the lifecycle
  • 64.
    B18 – execMode Goes Wrong • execMode and execId are very powerful • Be carefuly about execId and refreshId • Bonus – execMode demonstrates this • execId defines which control values get passed to component tree • refreshId defines which area gets updated on browser • If refreshId is larger than execId, controls outside execId will lose their values
  • 65.
    B19 - RepeatsRevisited • See Bonus – Language Performance + Rendered • rendered property set for each of 50000 rows • rendered property set in different ways • SSJS in Script Library performs worst • SL much worse on partial refresh • VariableResolver best for performance • Deprecated in JSF 2.0 for ELResolver • VariableResolver in OSGi plugin best for performance and reusability (check out XSP Starter Kit) • dataContext next best, but only reusable within page
  • 66.
    B20 – Comparisons If you're separating business logic from presentation, Java is the way to go