Is dot sign required for GetString method in ClipboardPage
Hi,
Can anyone give a logical explanation for my following experiments?
| 1 | tools.findPage(“pyWorkPage”).getString(“pxCreateOperator”) | Valid |
| 2 | tools.findPage(“pyWorkPage”).getString(“.pxCreateOperator”) | Valid |
| 3 | tools.findPage(“pyWorkPage”).getString(“pyWorkParty(Originator).pyWorkPartyUri”) | Inalid |
| 4 | tools.findPage(“pyWorkPage”).getString(“.pyWorkParty(Originator).pyWorkPartyUri”) | Valid |
This behavior doesn't sound logical to me, because for No.1 & 2, dot does not seem to be important. If it disregards dot sign, I would like to know which syntax is officially or formally correct.
Thanks,
Labb Consulting
GB
Hi,
The reason is probably the page context in which you are trying to locate your property. The string you are trying to locate in Scenario 3 is on an embedded page so it requires the full path to be given. Whereas in scenario 1 you are directly referencing the the property on the page you defined in findPage (pyWorkPage).
Regards
Sarah.
Pegasystems Inc.
AU
Nice reply, SARAH GODFREY
@CloeW938 , it is interesting that #4 is Valid, actually. The practice I tend to follow is:
- Use methods designed to work with "pages" when referencing pages, and
- Use methods designed to work with "properties" for properties.
- There are also methods for working with the page collections like Page Lists and Page Groups ... .pyWorkParty is a Page Group.
.pyWorkParty(Originator) is ultimately a page embedded in pyWorkPage. So (without having tried it recently), I would actually recommend a 5th option:
tools.findPage("pyWorkPage.pyWorkParty(Originator)").getString(".pyWorkPartyUri")
... the first method call narrows down to the page of interest; the second locates a property from that page. Other methods of interest that return a ClipboardPage reference (if the above doesn't work) include:
- ClipboardPage.getPage(String)
- ClipboardProperty.getPageValue()
- ClipboardProperty.getPageValue(int)
- ClipboardProperty.getPageValue(String)
I like always using the dot in the getString(...) call as it is more explicit, but as you've seen it doesn't seem to matter if the reference is a scalar property.
Nice reply, SARAH GODFREY
@CloeW938 , it is interesting that #4 is Valid, actually. The practice I tend to follow is:
- Use methods designed to work with "pages" when referencing pages, and
- Use methods designed to work with "properties" for properties.
- There are also methods for working with the page collections like Page Lists and Page Groups ... .pyWorkParty is a Page Group.
.pyWorkParty(Originator) is ultimately a page embedded in pyWorkPage. So (without having tried it recently), I would actually recommend a 5th option:
tools.findPage("pyWorkPage.pyWorkParty(Originator)").getString(".pyWorkPartyUri")
... the first method call narrows down to the page of interest; the second locates a property from that page. Other methods of interest that return a ClipboardPage reference (if the above doesn't work) include:
- ClipboardPage.getPage(String)
- ClipboardProperty.getPageValue()
- ClipboardProperty.getPageValue(int)
- ClipboardProperty.getPageValue(String)
I like always using the dot in the getString(...) call as it is more explicit, but as you've seen it doesn't seem to matter if the reference is a scalar property.
Beware of hard-coding pyWorkPage into your code. pyWorkPage may seem to be a safe assumption but there are occasional windows where it isn't. See some of the discussion here:
https://collaborate.pega.com/question/what-are-situations-lead-passing-pyworkpage-parameter
In your case, I would consider whether the Primary Page of the current rule is the one you're assuming to be pyWorkPage. If it is, I recommend you replace references like:
tools.findPage("pyWorkPage")
... with ...
tools.getPrimaryPage()
... and is where some of the above getPage* methods might come in handy.
Report back with how you go!