0

I'm using Expression language to give to a client-side Javascript function the ID of a particular DIV. I'm using this:

"#{id:repeatsecondlevelnodes}"

Firstly, I'm not at all sure how the resolver finds the 'real' ID. I'm assuming that it's something similar to CSS Selectors, but I have been unable to find authoritative documentation on it. I'd appreciate any link to any kind of documentation.

Secondly, I don't get why sometimes the resolved value is postfixed with :0

Sometimes I'll get

view:_id1:repeatfirstlevelnodes:1:repeatsecondlevelnodes:0

when I'm expecting

view:_id1:repeatfirstlevelnodes:1:repeatsecondlevelnodes

and I don't get what's causing the difference. So far I've hacked it by just removing :0 if I encouter it, but I'd rather understand how the resolver actually works.

the source of my confusion

Andrew Magerman
  • 1,394
  • 1
  • 13
  • 23
  • 1
    it is appended, not prepended, and please don't post code in screenshots. Thirdly, post the related source code of the xhtml/xpage. Short answer: it is added if you have iterating components like a datatable, ui:repeat or similar – Kukeltje Jan 30 '17 at 11:47
  • 1
    @Kukeltje: Normally their index doesn't end up in last place of the chain. Andrew: Here's some food for thought http://stackoverflow.com/q/12615556 Namely, you seem to be abusing IDs for ultimately the same common thing. – BalusC Jan 30 '17 at 12:19
  • @BalusC: true, forgot about that... – Kukeltje Jan 30 '17 at 12:30
  • @Kukeltje: Thanks for the comments. I'm not trying to generate those Ids manually. I just don't get why "#{id:repeatfourthlevelnodes}", in the case shown by the screenshot, resolves to '_id1:repeatfirstlevelnodes:0:repeatsecondlevelnodes:0:repeatthirdlevelnodes:0:repeatfourthlevelnodes:0' and not to '_id1:repeatfirstlevelnodes:0:repeatsecondlevelnodes:0:repeatthirdlevelnodes:0:repeatfourthlevelnodes' – Andrew Magerman Jan 30 '17 at 13:10

1 Answers1

0

"#{id: ... }" is a special expression to get the rendered client id of an XPage control id. It is executed on server side. The server knows what id the rendered client element will get.

Example:

The CSJS code definied in an XPage

var element = document.getElementByID("#{id:repeatsecondlevelnodes}")

will be modified by server before it get sent to client to something like

var element = document.getElementByID("view:_id1:repeatfirstlevelnodes:0:repeatsecondlevelnodes")

This will always work as the server knows the exact client ids.

Don't try to calculate the client ids by yourself as they might change when you change something in XPage. Just trust the "#{id: ... }" expression.

Knut Herrmann
  • 30,880
  • 4
  • 31
  • 67
  • Hi Knut and thanks for the answer. My use case is a little bit more complicated; the syntax of the CSJS is generated dynamically (it's part of a series of nested repeat controls). Linked with this: http://stackoverflow.com/questions/41912525/nested-expression-language-syntax-in-xpages. The thing which I am not getting, though, is why sometimes there is a :0 appended to the calculatedID. I'm trying to understand what causes the :0, and avoid it, I'm not trying to calculate the id by myself. – Andrew Magerman Jan 30 '17 at 13:02
  • I understand. Although, "So far I've hacked it by just removing :0" sounded to me like calculating the client id ;-) – Knut Herrmann Jan 30 '17 at 13:13
  • It's even worse than that, it's symptomatic treatment of bugs, and I hate that in other people's code, and it really really bugs me when I have to do it myself! – Andrew Magerman Jan 30 '17 at 13:16
  • Do you get the same wrong Client id "...:0" with `#{javascript:getClientId("repeatsecondlevelnodes")}` ? – Knut Herrmann Jan 30 '17 at 13:43
  • Now I can't seem to be able to reproduce the effect... Damn. – Andrew Magerman Jan 31 '17 at 14:11