Hallo,
Bernhard, dein Vertrauen in das Evaluate und die Formel-Engine und daß alles auch unter 8.5 so funktioniert wie früher ehrt dich. Umso erstaunlicher, daß du so ungern damit arbeitest. ICH arbeite damit, und ich traue dem Zeug immer weniger.
Ich versuche jetzt nochmals das Problem zu beschreiben:
Das ganze ist in einer Workflow-Engine eingebettet, diese wird seit Jahren problemos im Unternehmen eingesetzt. Mögliche Workflowschritte sind in Notes-Dokumenten (keine Profildokumente) abgespeichert.
Beschränkungen für diese Schritte werden in einem Formelfeld eingegeben, dieses wird bei Laufzeit ausgewertet. Der Agent wird durch den Anwender ausgelöst, und läuft mit seiner Berechtigung. Die DB liegt auf dem Server.
Ich hab den Dreck debuggt, bis ich Punkte vor den Augen gesehen habe.
Hilfsweise habe ich im Agenten die Formel in die beiden Hälften zerlegt, und einzeln ausgewertet, dabei ergab sich folgendes:
- der erste Teil, der auf die Rollen des Anwenders abprüft, ergibt immer das richtige Ergebnis (egal ob mit @contains oder @ismember, das funktioniert)
- der zweite Teil, der auf das Feld im Dokument geht, ergibt mal ein richtiges Ergebnis, mal ein falsches. Den Zugriff habe ich versucht via @getField("Feldname ") = "xxxx" sowie über Feldname = "xxxx". Das Feld ist auf der Maske vorhanden, berechnet, der Wert ist @thisValue, die Belegung erfolgt programmatisch. Es sind keine führenden oder nachfolgenden Leerzeichen enthalten (mehrfach überprüft, auch durch Kollegen).
Folgerichtig wird die Kombination dann auch falsch, wenn Ausdruck 2 falsch ist.
Wenn es falsch war, konnte ich das Item auf alle Fälle im Debugger nicht unter den Eigenschaften des Dokumentes sehen, da zu viele Felder im Dokument. Ich habe mir zur Hilfe einen String mit dem Inhalt des Items belegen lassen via doc.Itemname(0), der String war immer richtig belegt.
Die korrekte Schreibweise des Items und des Iteminhaltes wurde durch 3 Kollegen überprüft.
Eine Kollegin hat die Workflowdokumente und die eigentlichen Dokumente mit Ytria untersucht, es wurden keine Auffälligkeiten festgestellt.
Ich habe die Workflowschritte neu erstellt, ich habe die eigentlichen Dokumente neu erstellt ohne daß das Problem sich geändert hätte.
Daher war meine Idee, daß es mit dem Zugriff auf das Dokument etwas zu tun hat und dass aus irgendeinem Grund entweder der Zugriff auf das Dokument durch das Evaluate misslingt oder aber der Zugriff auf das Item selbst schiefgeht.
Das Ganze ist aufgefallen unter 8.5.2. (deutsch); evt. war das Problem auch unter 8.5.1 schon da und ist in der Entwicklungsphase einfach noch nicht aufgefallen/ untergegangen.
Unter 8.5.2 haben wir jetzt auch Probleme mit hasItem() in JavaScript, die wir unter 8.5.1 noch nicht hatten.
Vor 10 Tagen konnte ich das Problem an eine andere Entwicklerin weiterreichen, wenn sie etwas herausfindet, melde ich es. Bisher muckt es munter weiter.
Inzwischen bekam ich auf alle Fälle noch folgende Infos durch die IBM, die beziehen sich aber auf die XPages (ich kämpfe im Notes); Servereinstellung konnte ich noch nicht überprüfen lassen.
Public Detailed Description/Steps to Reproduce:
For RETAIN compatibility - use up to 200 lines at 64 characters per line.
Any information entered may become public information and viewable by
customers. Use the Other Info field for any internal information.
Open the xsp.properties file in data/properties folder of the server.
Change/Add a line to include: xsp.persistence.mode=file
Save the changes, and start/restart your server.
Open the XPages demo app.
Go to @functions -> @A*
In the drop down menu, select @AttachmentLength
This gives a runtime error (see below).
This error occurs for the following @functions: @AttachmentLength,
@AttachmentModifiedTimes, @AttachmentNames, @Attachments, @Author,
@Created, @GetField, @GetNumberField, @GetReaderField, @GetTextField,
@IsAvailable, @IsDocBeingLoaded, @IsDocBeingSaved, @IsError, @IsMember,
@IsNewDoc, @IsNotMember, @IsNull, @IsNumber, @IsResponseDoc, @IsText,
@IsTime, @IsUnavailable, @IsWebClient, @Modified, @Modulo, @Month.
If you use either of the other 2 settings: "xsp.persistence.mode=fileex" OR
"xsp.persistence.mode="; then there is no problem.
Behoben in V852_02112010.
Außerdem: SPR SRKM7YSFFX "@GetField is not working in XPages."
Public Detailed Description/Steps to Reproduce:
For RETAIN compatibility - use up to 200 lines at 64 characters per line.
Any information entered may become public information and viewable by
customers. Use the Other Info field for any internal information.
Create a new Database
Create a new xPage
Drag and drop EditBox and name as 'Subject' and set default value as "test"
Drag and drop a Computed field control on to the xPage
Select the Computed Field and from the Properties select Value. Select
JavaScript.
Add following script as computed value for the above added control:
@getField("Subject")
Save and open the Xpage on the web.
@getField does not capture the value of the Subject field value.
Behoben in V852_01122010. Es gibt einen Hotfix!