Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

what's the benefits of using data context in xPages?

I have never used data context in xPages and would like to know the benefits,

If I want to return something in memory I often call function in a SSJS scriptlibrary which I believe is also stored in memory.

so let's say I have a function in ssjs that returns a notesdocument, this function might be called from several places in my xpage. will data context be benefitial in this case in regrards to having a function in a ssjs scriptlibrary.

like image 760
Thomas Adrian Avatar asked Feb 21 '23 08:02

Thomas Adrian


2 Answers

dataContexts can be thought of as global variables. The advantages over SSJS functions are:

1) The dataContext runs the SSJS / Java / whatever are returns the value. References to the dataContext use EL (e.g. #{myVar}), the same as datasources. So my understanding is that the EL gets the value, rather than running the SSJS / Java code each time. So there's a performance benefit there.

2) The dataContext's value can be computed dynamically or on page load. So you can use ${javascript:@Today()} and run it once rather than running a function each time.

I suspect there's also a performance benefit because references to dataContexts use EL. So at no point in the references do you run SSJS, so it's not having to go through the SSJS parser.

The additional benefit of dataContexts is they can be scoped to any level that datasources can - so XPage, Custom Control or Panel. This gives them an advantage over viewScope. So youo can also set a dataContext in a panel in a repeat control, to avoid multiple references to a NotesDocument's field or concatenation of fields.

I've tended to avoid storing Domino objects in dataContexts, mainly because of the inherent risks of recycling. I don't know if there's an issue, I'

like image 70
Paul Stephen Withers Avatar answered Mar 06 '23 20:03

Paul Stephen Withers


@Withers: #{MyVar} I found did not work when I used my DataContext variable #{DataStoreDbName} in the dblookup: (I do however find your posts very valuable Mr. Withers)

These didn't work:

#{DataStoreDbName}
@Sum(@DbLookup("#{DataStoreDbName}","personnelbudget",compositeData.catid,10))

#{id:DataStoreDbName}
@Sum(@DbLookup("#{id:DataStoreDbName}","personnelbudget",compositeData.catid,10))

This Did Work

I like the way dataContext var's show up in the list of DataSources in the Data section of the Properties Tab of the Control under which the DataContext was entered.

  1. Start with defining the DataContext: var = DataStoreDbName

  2. This Data Context variable is an external database of Server:DB that I am using in @DbLookup's.

    "DataStoreDbName" variable name now shows up in the Data sources under the Data Section:

  3. This is the DbLookup I am using the DataContext in: @Sum(@DbLookup(DataStoreDbName,"personnelbudget",compositeData.catid,10))

enter image description here

  1. Above is an example of another DataConext (obviously), but here is how the variable name was used in computations in fields or customCoverters of Hidden fields (which makes hidden fields act like computed fields in Notes). *Notice @Text()'ing the sum to avoid throwing an error.

enter image description here

The <xp:text> simply shows the DataContext variable value, while the <xp:inputHidden> uses the DataContext variable value in the customCoverter to store/persist the value on Submit/Save.

like image 36
Sean Haggerty Avatar answered Mar 06 '23 19:03

Sean Haggerty