Xpage, createForm=false disables SSJS events on li

I ask this just to be clear here: I accidently set the createForm property to false. I then expected a link event that should open another page only not to function any more. Is this the intended behavior of SSJS events e.g. in links when you disable form creation?

回答1:

As Per mentions, all events require a form: if they are full refresh, then the page needs a form to post to in order to trigger the redirect; if they are partial refresh, the form determines the contents of the AJAX POST.

The XPages runtime includes support for a form component, but it is not included in the component palette (and it cannot be added via Designer Preferences), so the only way to add it to a page is by editing the source XML directly. For example:

<xp:form>
    <xp:link id="exampleLink" text="Example Text">
        <xp:eventHandler event="onclick" submit="true" refreshMode="complete">
            <xp:this.action><![CDATA[#{javascript:// event code}]]></xp:this.action>
        </xp:eventHandler>
    </xp:link>
</xp:form>

There are (at least) two reasons why this component is useful:

It can improve performance. If a page contains different areas that are functionally distinct -- in other words, an event in one portion of the page does not need to be aware of data in any other portions of the page -- then wrapping each section in a separate form component causes each event to only post data that is contained inside the same form as the component that triggers the event. Your question indicates that the link that broke when you set createForm to false should navigate the user to another page; it's likely, therefore, that this event doesn't need to know about any field values, because the user is leaving the current page anyway. If that's true, wrap this link in its own form, and any fields inside a separate form, and the link will perform marginally faster because the browser doesn't have to post any field data... just the identifier for the link itself.
It can provide style flexibility. It's common for a developer to receive, separately from the actual end user requirements, pre-determined CSS from a designer unfamiliar with Domino -- for instance, if the site design is outsourced, or must adhere to corporate style guidelines. This often becomes a source of tension when the designer has made certain assumptions that, at first glance, are incompatible with the markup that Domino generates. One of the most common examples of this is when the site contains search features, because most web developers will have one form for search and a separate sibling form for any other fields. This can increase the cost of a project when either the designer or the developer has to revise a stylesheet that the designer already developed to account for a single form tag surrounding all the content. In short, suppressing the default form element and explicitly specifying form components where needed makes it easier to adhere to externally imposed style guidelines.

So there are many use cases where it's actually preferable to use one or more form components on an XPage... just remember that all data and events must be inside a form -- whether the default form that usually surrounds all the content, or a manually included form component -- and that forms cannot be nested. You can add as many form components as you want, but they must be siblings. No form can contain another form.

回答2:

Yes, because you are doing HTTP POST requests and they require a form.

You can convert your POST request link to a GET request link instead be removing the SSJS event and creating a "basic" link instead:

<xp:link escape="true" text="Link" id="link2" value="/somepage.xsp"></xp:link>

But if you need the SSJS logic, then you also need to have a form.