CODEWITHSUNDEEP
xpages
Michael Saiz
Michael Saiz

Reputation: 1640

why does xPage process my Comments as though they weren't

I got a strange behavior in XPage, with commented Code.

I had a textfield with a lot of code in it which outputs html where I hit this issue. While developing I had a lot of trouble with some fields other fields so I decided -to get a better idea what the field is doing- to copy the code from the troublefields to a comment inside my textfield to have the other code at my sight. But then the xPage started to behave strange until I found the issue.

The Code below is a example what caused my issue, it has two text fields in it one which sets a scope var and also has a comment which sets the same var but commented, ant another one which shows the ScopeVar. I thought this would output 'where I am' in the second text box but instead I got the 'Huhu I am here'.

        <xp:text escape="true" id="computedField7">
            <xp:this.value><![CDATA[#{javascript://
                sessionScope.put("findme","where i am");
                /* #{javascript:sessionScope.put("findme","HuHu I am here!");} */
                return sessionScope.findme;}]]></xp:this.value>
        </xp:text>
        <xp:br></xp:br>
        <xp:text escape="true" id="computedField6"
            value="#{javascript:return sessionScope.findme;}">
        </xp:text>

In my original Code where I hit this issue I wanted to comment the old #{} el out to use a JavaScript instead but keep the el in comment in the middle of the code.. same result. It seams that if you use #{ or ${ in a comment it will always get computed!

Got this fixed in notes 9. I am currently using 8.5.3.

Update: As a small note: Be careful when using the dojoAttribute queryExpr because the query Looks like SSJS "${0}" and also gets interpreted as SSJS. I now use this:

<xe:this.queryExpr><![CDATA[${javascript:"*$\{0}*";}]]></xe:this.queryExpr>

to make it work. Thanks to Paul Stephen Withers for the tip with the \{.

Upvotes: 2

Views: 576

Answers (2)

Paul Stephen Withers
Paul Stephen Withers

Reputation: 15739

Is there a reason for having #{javascript:...} nested inside #{javascript:...} in your example. I'd strongly recommend against that, I wouldn't expect it to give good results.

Please see my answer also to stopping getClientId() computations in JS code. I think you're expecting it to work in a way it's not designed and unlikely to be changed to work.

Properties are just strings read at runtime from left to right. If "#{javascript:", "${javascript:" or "#{.." are found, the resulting code is run. Wrapping "//" around them or "/" and "/" either side has no effect, nor would I expect it to. The whole string is not passed to the parser, just the bit after "#{javascript".

The benefits of this are that you can get better performance by combining languages because only part of it gets passed to the parser and literal string (which is what the "/*" bit is) is just passed to the browser as it is. It means you can include EL and SSJS in a single value. I'm not sure you'd be able to do that if the change you're looking for was made.

For queryExpr, I'd suggest using ${javascript:"${0}"} instead - just escaping the {. See p121 XPages Extension Library.

Upvotes: 1

Knut Herrmann
Knut Herrmann

Reputation: 30970

This is a funny bug.

It is caused by pre-processor functionality of JavaScript interpreter. Normally, you can write #{javascript:...} in CSJS code to replace parts of code before it gets put to rendered page.

In your case it is SSJS. Again, the interpreter replaces the #{javascript:...} inside your SSJS code and thinks, work is done. This way you see the code on rendered page instead the result of executed code.

rendered page

As a workaround, just delete # from /* #{javascript... and it will work like expected.

Upvotes: 1

Related Questions