Question

Users open documents by links in old format http://server/db.nsf/VIEW_UNID/DOC_UNID. The form has property set to open XPage instead.

Origin of these links is email notification generated by “universal agent”. It simply sends link to document. It does not know, what form is associated with what XPage, therefore it generates universal links instead of “/page.xsp&documentId=…”.

The problem: relative links computed at client do not work – < a href = "/page.xsp?params"> should be more effective – no roundtrip and easy to compute at page load. They evaluate to http://server/db.nsf/0/page.xsp?params, what ends with Error 404, naturaly.

XPage contains “help” section, what is another document with RT field containing text, images and links. And relative links in that RT field work when XPage is opened from another XPage – view (/page.xsp), but fail when redirected from notification link (/0/UNID).

Question: How to effectively reset browser’s address bar to extended XPages format http://server/db.nsf/page.xsp?documentId=DOC_UNID after opening redirected documents/views by old fashioned URLs?

Answer 1

Main problem is in discrepancy of relative links on server side (evaluated in SSJS) and client side (evaluated by browser). I have solved my problem by simple redirect in case document is open by old fashioned link.

<?xml version="1.0" encoding="UTF-8"?>
    <xp:view xmlns:xp="http://www.ibm.com/xsp/core">
        <xp:eventHandler event="onClientLoad" submit="false">
            <xp:this.script><![CDATA[var url = "#{javascript:context.getUrl()}";
    var l = window.location;
    if (url != l) {
        window.location.replace(url);
    }
    ]]></xp:this.script>
    </xp:eventHandler>
</xp:view>

Simply said, if open URL differs from internal URL (as resolved by XSP engine), browser redirects to correct URL. This solved many problems we had with inline images (image resource) and attachments.