The Discussion template has gotten a further update in 852 so that it performs better and has a better user experience.

For Release 8.5.2, the XPages user's guide in the product documentation has been revised. It now includes reference topics for all controls and properties. The overview and other material has also been redrafted. Work is on going to improve this guide.

Upgraded to Dojo 1.4.3 for the server and XPiNC. The server install will also include a further upgrade to 1.3.x to Dojo 1.3.3.

Dojo Type and Attributes added to more controls (including scriptBlock)

Support for dojoForms (dojoForm="true")

onClientLoad Event. Its now possible to add scripts in the events to be executed when the page is submitted or this panel or some containing panel is partial updated.

Assigns credentials based on the signer of the of XPages design element. The session is restricted by the application's ACL and the security tab of the server's Domino Directory entry.

Assigns credentials based on the signer of the of XPages design element and allows full administrative access to the application's data. The signer must have the right to such access or the session is not created.

New resource xp:headTag - this allow you in an easy way to put stuff into the header of a XPage - and here is an example of it's use - http://heidloff.net/article/quick-tip-prereq-to-run-xpages-on-blackberry

HTML5 cache manifest support. This offers off-line capabilities. See Niklas Heidloff's OpenNTF post http://www.openntf.org/blogs/openntf.nsf/d6plinks/NHEF-85588X and Mark Hughes'shttp://julianbuss.net/xpages-am-i-the-only-one-fighting-with-validation-on-every-partial-update-htm/

HTML5 Base resource support - pageBaseUrl property renders as a base tag in the header. The <base> tag specifies a default URL and\or a default target, for all elements with a URL.

The runtime has switched over to use the OSGi framework. All the XPages libraries (which are under xsp/nsf/lib in 851) have being moved to the OSGI framework under the shared eclipse location.

New support has been added for the loaded attribute to complex types. This will allow for a way to conditionally define a complex objects like a dominoDocument on an XPage.

A new version fully available - oneuiv2. Try out these new themes: oneuiv2, oneuiv2_green, oneuiv2_gold, oneuiv2_metal and oneuiv2_red.

Allows for the calculating of the Last page in a data collection for the Pager. In 851, there is a restriction on the number of pages the Pager will display. This is because of associated performance hit (this is still the case with this new property). However, customers have asked for an option to calculate this regardless. The 'alwaysCalculateLast' property, new to 852, allows you to do just that.

Further enhancements in the Java back-end classes help XPages perform better.

Repeat Control enhancements - "xsp.repeat.allowZeroRowsPerPage". This option may be useful when you need to compute the number of rows to display as there may be situations where no rows should be displayed but the Repeat control should still render.

XPages in the Notes Client, Release 8.5.2, supports calling Java Agents to run locally on the Notes Client. Previously, only Agent.runOnServer() was supported where the NSF containing the XPages application and Java Agent were stored on a Domino Server.

More details can be found here, Running Java Agents from XPages in the Notes Client.

In V851 of XPages, security for executing Java code in XPages in the Notes Client was very restricted. For XPages V852, the Java Permissions managed by the XPages ECL settings have been broadened to be similar to the set of Java Permissions allowed by Java Agents and to bring a level of equivalence between Java Permissions allowed for XPages on Domino Server (Unrestricted) and XPages in the Notes Client. For example, in V851 the ECL Network permission only covered the Java SocketPermission, now it covers NetPermission and other related Java network permissions.

Public Access enables users to view (or create and edit) documents in cases where the user has not been explicitly granted access as either a reader or author of a particular document.

Up to now XPages applications were prevented from running if the user accessing the application only had the ability to read and write to Public Access documents. Now, in XPages Release 8.5.2, application designers can make XPages design elements available to Public Access users by setting the "Available to Public Access users" property in the Security sections of the Properties tab for an XPage.

Once an XPage has been made available to Public Access users, the user will only see

• documents

1. that have been created from a form which the "Available to Public Access users" property set and
2. also contain a text field named $PublicAccess with a value of 1

• contents of views

1. that have the "Available to Public Access User" property set in the access control options for the view (and only those documents that are available to Public Access users will appear in the view).

More details can be found here, XPages Public Access Support.

Referencing a Managed Bean from JavaScript now supported in XPiNC. This fixes a bug where a Managed Bean, first referenced in JavaScript (which triggered the creation of the Bean) caused a security exception. The workaround was to first have this Managed Bean referenced and created as a DataSource (referencing the Bean from then on was fine). This bug is now fixed.

Redirect XPages design elements to other databases.

XPages treats each NSF as a separate J2EE module, running in its own environment and loading its own objects. This ensures the complete isolation of each NSF. But, in some cases, a set of NSFs may share the exact same XPages, for example, MailBox databases or Quickr places.

Although the one NSF module works by having all the databases inheriting from the same template, it is not optimal in term of server resources as the same objects (design elements, java classes...) are read independently from each NSF, and retained in memory. This is also not optimal from a browser standpoint, as the same resources (.js, .css...) are coming from different URLs, which makes the browser caching less efficient.

The solution is to store the XPages design elements (XPages, Custom Controls, CSS, client/server JS libraries, themes) in a single NSF. Then, each database instance can point to the common "template" database through a new database property available in Designer.

Right Click on the Application in Designer and select Application -> Properties. Select the XPages tab and navigate to Performance section.



At runtime, XPages will read this information and if Single copy XPages design is enabled, it will then use the XPages related design elements from the "template" database instead of the current database.

More in-depth details can be found here http://www-10.lotus.com/ldd/ddwiki.nsf/dx/Single_Copy_XPage_Design
and here http://xpages.info/XPagesBlog.nsf/dx/single-copy-xpage-design-another-piece-of-xpages-magic.html.

Save Only Validation - disableValidation property - allows you to process data without validation and so firing the validation when it really matters. Resolves http://julianbuss.net/xpages-am-i-the-only-one-fighting-with-validation-on-every-partial-update-htm/

Very much like 'keys', startKey allows you to filter the view to start at a certain value.

This is an addition to categoryFilter that allows you to filter a view by the category and then the sub-category.

XPages developers now have a option in the Pager control to calculate the last page in a view, so that a user can go directly to that page without having to scroll though all intervening pages. Note that there is a performance penalty for calculating the last page.


More details can be found here, XPages and Views in V852 - Multiple Category Filters, Start Key, and Goto Last

XPages in the Notes Client, Release 8.5.2, supports calling Java Agents to run locally on the Notes Client. Previously, only Agent.runOnServer() was supported where the NSF containing the XPages application and Java Agent were stored on a Domino Server.

More details can be found here, Running Java Agents from XPages in the Notes Client.

Related to Agents, and new in V852, the following NotesAgent methods are supported: NotesAgent.run, NotesAgent.runWithDocumentContext, and NotesAgent.runOnServer. Note that when run locally in the Notes Client, security is based on the client ECL settings for the signer of the agent.

More details can be found here, XPages and Calling Agents Using an In-Memory Document.

New for Lotus Notes and Domino Designer 8.5.2 is the ability to optionally open XPage links and documents in a separate window or tab within the Notes client. This behaviour is specified at application design time and is set using the 'Window behavior' property in the user interface. The example below is for a Link.



The 'Window behavior' property has three possible values:

1. Use default
2. Open in same window and tab
3. Open in new window or tab (per Client preference)

Option #1 is the default value for all design elements so the behavior of existing XPages applications will not change. The 'per Client preference' mentioned here is the 'Windows and Themes -> Window Management' preference. This preference has the following three options and if option #3 above is selected, then this preference will be used to determine Window behavior.

1. Open each document in its own window
2. Open each document in its own tab
3. Group documents from each application on a tab

The 'Window behavior' property can be set on the following XPages design elements, and are listed in hierarchical order. Each child element will inherit its parent's behavior by default, unless the child is explicitly changed. So take care when setting this property at the Server or Application level.

• Notes client
• Server
• Application
• XPage
• View
• Link

These new properties will be ignored by Notes 8.5.1 clients.

This menu option now available when an app is launched in XPiNC.

Menu option now available for a XPages app is launched in XPiNC

XulRunner in XPiNC has been upgraded to 1.9x, which is equivalent to Mozilla 3.x.

Adds the ability to Close a Window from a Client Side JavaScript event. Needs window.open() for window.close() to work.
For example, create two XPages, b01.xsp and b02.xsp.
On b01 add a button, and add a client side event to open a new window for b02.



Then on the b02 xpage add another button to close the window



All this will work on a browser and on XPiNC