Posts Tagged ‘Internet Explorer’

Stolperfalle: Ids bei clientseitigen Events

Heute bin ich mal wieder über einen Fehler gestolpert, welchen ich schonmal begangen habe, und dadurch mal wieder viel Zeit verloren habe. Deshalb landets jetzt hier, in der Hoffnung dass ichs mir auch endlich mal merke =)

Ich hatte ein xp:div Element, welches eingebettet einen Text und ein Bild hatte. Mit einem onMouseover Event wollte ich die URL des zu verwendeten Bildes ändern. Leider reagierte das Element auf keinen MouseOver.

Dies kann man übrigens auf 2 Arten erreichen:

document.getElementById("#{id:zielElement}").src = "url_zum_bild.gif";

oder wenn man sich auf das aktuelle Element beziehen möchte, auf welchem das Event liegt:

	if (thisEvent.originalTarget) {
		thisEvent.originalTarget.src = "btn_go_Hover.gif";
	} else {
		thisEvent.srcElement.src = "btn_go_Hover.gif";

Die If-Abfrage hat den Hintergrund dass der Internet Explorer “srcElement” braucht und nicht auf originalTarget zugreifen kann.

Dass mein xp:div auf kein Event gehört hat lag einfach daran dass mein xp:div Element keine ID hatte.

MERKEN: Elemente mit einem clientseitgen Event brauchen IMMER eine ID!!

Btw: Wo wir gerade bei xp:div sind:

Mann sollte immer, wenn man nur ein einfaches div in der Seite braucht, xp:div verwenden. xp:panel hat zwar das gleiche Ergebnis, allerdings werden bei xp:panel noch ein paar Sachen im Hintergrund geladen die es ermöglichen eine Datasource anzubinden. Wenn man dies beachtet kann man noch ein paar Quäntchen Performance aus der Applikation herausholen. Besonders wenn man diese Elemente in einem xp:repeat loopt.


XPages: Set headers

08/11/2011 2 comments

Because today is Tuesday, there’s another advice:

You have the possiblity to set meta-headers in XPages. To do so, you have two possiblities.
1. In the properties of the XPage, you can add a ressource with the type metaData (see it on this picture)
2. Add a few lines of code to your BeforeRenderResponse event, like this:

try {
   var response = facesContext.getExternalContext().getResponse();
   response.setHeader("Expires", -1);
   response.setHeader("Cache-Control", "no-cache");
   response.setHeader("IE=EmulateIE7", "X-UA-Compatible");
} catch (e) {}

Propably, you would think it wouldnÄt matter where to do this, but remember, we are dealing with XPages…

Some headers can’t be set with the first method. I don’t know exactly at which point they are rendered, but sometimes, they are alrady there.

That means, when you want to add the header IE=EmulateIE7, which was described as a workaround in a former post by me, you should do this via the scond method in the BeforeRenderResponse. Else, you receive a browser warning, that this header will be ignored, because the doctype was already set. If you add it in the event, everything works fine and the header is rendered.

The funny thing is, there header is rendered with the first method, anyway, but he gets ignored because he seems to be set too late.

XPages: Collection of advices

Hi folks,

here is a small collection of some hints which were written by my colleagues and myself throughout time.

Naming of attributes in Internet Explorer

It seems, in the Internet Explorer, Dojo has some problems finding the correct element, while usingattribute selectors, if there is a string reserved by the system in the attribute. (e.g. name or id). Because Dojo uses the selector engine “Sizzle” like JQuery, the same phenomenon can appear using JQuery.

An example for that is an input-field with the name “username”. If you select dojo.query(‘input[id$=”WFApprovalVFL”]’) the field “username” will be selected, too, although it doesn’t end with WFApprovalVFL.

The same happens with keynames in JSON-objects.

Not rendered datasources will always be computed

If you use a datasource in a custom control, the code of the datasource will always be computed, no matter whether you set rendered or loaded to false. The code will always be computed. This could lead to errors hard to track down.

Furthermore, if you use several datasources in different custom controls, which point to the same document, all these datasources will be saved and, eventually, the document is saved more than once with saveing conflicts. To avoid this, you can reference the datasource in your custom controls directyl via the name, or you can pass on the datasource via a parameter of the custom control (compositeData). Therefore you have to select the class of the datasource, which doesn’t appear in the list of available types. The name of the class of a datasource is

Check whether a viewPanel is categorized

If we have a view control in our XPage which name is viewPanel1 the following code:

var = getComponent("viewPanel1").getDataModel();
return model.getCategoryIndentLevel();

returns the value 0 if view is categorized, it returns -1 if not.

Use case: If you sort a view, the content of a categorized column gets lost. With that you can check whether the view was sorted and reset the view.

Avoid the onChange bug in Internet Explorer when clicking on a CheckBoxGroup

If you use RadioButtonGroups or CheckBoxGroups in an XPage or a custom control, you could face the problem in the Internet Explorer, that after a partial refresh the submitted values of the group are the values from a previous request. This occurs if you click the label of instead of the box, directly. The reason is that the IE submits the partial refresh before setting the new value from the UI.



There is a CheckboxGroup with the options A, B, C and D. In the onChange event, a partial refresh will be fired on another panel, which hides or shows some elements in dependence of the chosen value. If you click the label for Option A, there is no submitted value. If you click the label of option B, the value A is submitted. If you click after that on the label of option C, Ab and B will be submitted.


You can fire the partial refresh a second time in the onComplete event of the onClick event.


The workaround above doesn’t work if there are additional actions or server-side code. The code will be executed only on the first refresh. To get this event-handler working again, you have to hang out the click-event from the standard-action and execute it by yourself. You can achieve that with a scriptblock (The name of the control is Output-Script, you can find it if you open the list of other controls in the sidebar of the Domino Designer) Because the checkbox itself is inside the label, you have to seperate it from the own execution.

 <xp:scriptBlock id="scriptBlock1"
            if ( != "checkbox") {

Another advantage of this method, compared to workaround 1, is that you don’t need a second request.

Validation of two dependen input-fields

While validating two fields dependent of each other, you have to read the value of the field which is validated. If you compare the value of the second field, validation will not be fired after the first fail and the validation error persists.


 <xp:inputText id="recipientNotesID"
   disableClientSideValidation="true" required="true">
      <xp:validateRequired message="Required value."></xp:validateRequired>
<xp:inputText id="recipientNotesPW"
   disableClientSideValidation="true" required="true">
         <xp:this.message><![CDATA[#{javascript:"Values must not be equal."}]]></xp:this.message>
      <xp:validateRequired message="Required value."></xp:validateRequired>
%d bloggers like this: