Some interesting new xsp.properties were introduced with Notes 9:
- xsp.client.resources.uncompressed
When set to true, all Dojo libraries and CSS resources where delivered in the uncompressed version. The path changes f.e. to /xsp/.ibmxspres/dojoroot-1.8.1-u/dojo/dojo.js.
- xsp.client.script.dojo.html5attr
When set to true, the Dojo HTML5 Data attribute is added to all Dojo component on the XPages. Here is an example for a Date/Time field:
<input type="text"
id="view:_id1:inputText1"
name="view:_id1:inputText1"
class="xspInputFieldDateTimePicker"
data-dojo-type="ibm.xsp.widget.layout.DateTextBox"
iconStyleClass="xspInputFieldDatePickerIcon"
constraints="{datePattern:"dd.MM.yyyy",timePattern:"HH:mm:ss",selector:"date"}">- xsp.radiobuttongroup.item.label.prefixSpace
When set to true, a blank is added before the label the label:
<xp:radioGroup id="radioGroup1">
<xp:selectItem itemLabel="Untitled" />
</xp:radioGroup>Resulting HTML code (There is a space before the red marked label):
<label for="view:_id1:radioGroup1:0">
<input type="radio" id="view:_id1:radioGroup1:0"
name="view:_id1:radioGroup1" value="Untitled"> Untitled</label>New properties which are described in the xsp.properties.sample file:
- xsp.maximum.mime.tree.scanLevel
- com.ibm.ws.webcontainer.HTTPOnlyCookies
- xsp.client.script.xspClient.preventLayer
- xsp.client.script.radioCheckbox.ie.onchange.trigger
- xsp.repeat.parseSingleStringAsInt
- xsp.client.script.dojo.loader
„xsp.client.script.radioCheckbox.ie.onchange.trigger“
I’m interested in hearing what the implementation of this is. Does the rendering just detect IE and move the onchange event code to the onclick? Or does it emit better HTML markup for the radiobutton group that properly puts the label outside the radiobutton tag?
It adds the attribute onchangeTrigger to the generated HTML. In xspClientDojo.js you can find how they solved the problem:
Where can I find the sample xsp.properties?
„New properties which are described in the xsp.properties.sample file:“
Interesting post as always 🙂
You can find the sample xsp.properties file in the directory NOTESDATA\properties\.
Thanks for Sharing Sven – love the IE Hack 🙂
There is a checkbox in the new xsp properties editor to enable uncompressed dojo resources! 🙂
Thanks for the info! I am still unable to install a Notes 9 Designer on my laptop (it was no problem to install a Domino server). That’s why I could not check if there is an option for this. 😉
See here: Notes 9: No Comment!
Can you give me some information about the xsp.client.script.dojo.loader property?
„com.ibm.ws.webcontainer.HTTPOnlyCookies“
That sounded promising to set the HTTPOnly flag on the Domino session authentication cookie (DomAuthSessId). Unfortunately that doesn’t work: probably because of the fact that these settings are for the XPages runtime only. A login through a (custom) session authentication form doesn’t pass that: it gets the session cookie from the POST result to (normally) names.nsf.
Hallo Sven,
vorab möchte ich mal danke sagen für deine vielen professionellen Blog-Einträge,
ohne diesen wäre die tägliche Auseinandersetzung mit XPages noch mühsamer.
Nun zum konkreten Problem:
Der „xsp.properties“ Eintrag „xsp.client.script.dojo.html5attr“ würde sich wunderbar
anbieten, wenn man eine XPages Anwendung für HTML5 entwickeln möchte.
Nur leider ist es unrealistisch, eine solche Anwendung ohne Zuhilfenahme der
Extension Library umzusetzen.
Aber genau hier fängst wieder mal an – wie so oft mit XPages – Probleme zu bereiten.
Folgendes Szenario (Domino 9.0.1 FP3):
a) xsp.properties (xsp.html.doctype=html, xsp.client.script.dojo.html5attr=true)
b) XPage mit einem Dialog (xe:dialog) in dem einzig ein Titel „Dialog“ gesetzt wurde
Führt beim Versuch den Dialog zu öffnen, zu folgendem Fehler (Firebug Console):
xspClientDojo.js (Zeile 1193)
SyntaxError: illegal character in data-dojo-props=’\“title\“:\“Dialog\“‚
Hätte mir erwartet, dass das Attribut folgendermaßen gesetzt wird: data-dojo-props=“title: ‚Dialog'“
Leider schafft es IBM immer weniger durchgängig halbwegs fertige
und stabile Software auszuliefern 🙁
Danke vorab für jegliches Feedback
Schöne Grüße
Georg
Ich habe mir den Spaß gemacht, dass mal etwas näher anzuschauen, und siehe da: Das ist tief in den Core-Klassen verwurzelt, es wird aus den Dojo Properties ein String generiert, der dann wiederum nochmals escaped wird.
Da sehe ich schwarz…
Ist mir bisher nie aufgefallen, da ich meine HTML5-Applikationen immer ohne ExtLib gebaut habe. Zum Teil mittels eigenen Komponenten, als auch mit xp:attrs, um mir die nötigen Tags zu erstellen.
Ich habe mir die Frage mehr als einmal gestellt, ob ich die ExtLib in meinem Projekt einsetzten soll oder nicht. Leider habe ich mich dafür entschieden und es schon des Öfteren bereut 🙁
Danke für deine Antwort.
Meiner Meinung nach, war es ein strategischer Fehler von IBM – zu glauben – die alt eingesessene Entwickler Community nicht zu verstören – sie nur ja nicht mit Technologien wie Java, HTML, CSS oder auch modernen Frameworks zu konfrontieren. Lieber ein bisschen SSJS, Simple Actions da, ein bisschen ExtLib dort, etc. am besten immer viele Wege nach Rom, anstatt einer durchgängigen konsequenten Vorgehensweise.
Es fehlen einfach klare Ausrichtungen, Dokumentation, Best Practices, etc. sehr wenig bis nichts von dem gibt’s bei IBM im Domino Umfeld. Du musst dir alles mühsam zusammentragen. Vieles im Bezug auf Technologieeinsatzentscheidungen muss leider oft auf Annahmen basieren.
Schöne Grüße
Georg