Das Notes Forum
Domino 9 und frühere Versionen => ND8: Entwicklung => Thema gestartet von: Ruedi am 10.05.11 - 12:58:44
-
Vielleicht ist das folgende Problem allgemein bekannt. Falls nicht, mag es dem einen oder der andern helfen:
Bis 8.5.0 (?) konnte der Aliasname eines Agenten frei gewählt werden. Ab 8.5.1 (?) wird der Aliasname bei Agenten des Typs "Agent list selection" von runden Klammern umgeben.
Dieses Problem stellt sich auch bei bestehenden Agenten, deren Aliasname geändert wird. Danach enden Formeln der Form @Command([RunAgent]; "AgentAlias") mit einem Fehler. Die Formel @Command([RunAgent]; "(AgentAlias)") hingegen funktioniert.
Wird der Name des Agenten mit runden Klammern umgeben (beim Erstellen oder beim Umbenennen), kann der Aliasname weiterhin frei gewählt werden - solange der Agent vom Typ "Action menu selection" ist. Wird der Agenttyp von "Action menu selection" zu "Agent list selection" geändert, ändert sich der Aliasname nicht. Wird hingegen der Aliasname geändert, wird er zwangsweise mit runden Klammern umgeben, falls der Agent beim Abspeichern vom Typ "Agent list selection" ist. Deshalb beim Umbenennen des Aliasnamens auch den Agenttyp kurz ändern und danach wieder zurücksetzen.
-
Das war schon immer so.
Agent list selection bedeutet der Agent ist unsichtbar deshalb die Klammern.
Action menu selection Agent ist sichtbar (sonst könnte man ihn ja auch nicht starten) deshalb auch ohne Klammern.
Boris
-
Aliase bei Agents scheinen eh nicht unkritisch zu sein. Ich bin gerade unter 7.0.4 und 8.5.2 auf die Nase gefallen mit NotesDatabase.GetAgent - da fand er einen Agent mit Aliasnamen nicht (Alias und "Klarname" waren identisch).
Bernhard
-
Das war schon immer so.
Agent list selection bedeutet der Agent ist unsichtbar deshalb die Klammern.
Action menu selection Agent ist sichtbar (sonst könnte man ihn ja auch nicht starten) deshalb auch ohne Klammern.
Boris
Nein, das war eben nicht immer so. Bisher wurden Klammern um den Agentennamen gesetzt, um den Aufruf aus dem Menü zu verhindern. Auf den Aliasnamen hatte das keinen Einfluss.
Was mir bei der heutigen Lösung nicht gefällt, ist, dass der Aliasname des Agenten automatisch ändert, abhängig vom gewählten Typ. Das führt wohl früher oder später zwangsläufig zu Problemen.
Ruedi
-
Wer sich mit den Thema mal etwas intensiver beschäftigen will, sollte mal mit der NotesNoteCollection rumspielen. Und da speziell mit dem $Title. Was einem da unterkommt lässt einem hässliche Schauer den Rücken runterlaufen.
-
Richtig - eiskalte Schauer!
Bei Designelementen mit Alias steht in $Title ein Array. Im Agent ist es ein skalarer Wert. Das kann nur jemand mit 2,8 Promille Blut im Alkohol ausgeheckt haben!
Bernhard
-
Helfen kann ich auch nicht, aber das war tatsächlich schon immer "falsch", nur hat IBM es jetzt "richtig falsch" gemacht:
Agenten mit "Agent Selection" und Alias wurden in Versionen <= 7 tatsächlich so abgespeichert:
Name: (AgentenName
Alias: Alias)
In 8 / 8.5 wurde das geändert, dass der Agentenname in Klammern gesetzt wurde, und der Alias in Ruhe gelassen wurde (so wie ich das für "richtig" empfinden würde).
Und seit (ich meine) 8.5.2 ist es jetzt so, dass Name UND Alias in Klammern gesetzt werden.
Maureen Leeland, die Designer- Entwicklungs- Chefin ist übrigens überzeugt, dass es SO jetzt richtig ist, wie Sie auf dem letzten Entwickler- Camp mitgeteilt hat... Ich finde das schlimm...
Ich muss aktuell die Aliasse von Agenten immer manuell in der Agentenliste umbenennen, nachdem ich einen Agenten gespeichert habe, weil sonst meine ganzen gemeinsamen Aktionen nicht mehr funktionieren.
Das schlimmste: Der Workaround, den man früher machen konnte, indem man einfach "Auswahl aus Aktionen" ausgewählt hat, und dann den Namen in Klammern geschrieben hat, funktioniert auch nicht immer, weil teilweise die Klammern beim speichern einfach wieder entfernt werden (aber irgendwie auch nicht konsistent)...
Bin gespannt, ob die das irgenwann auf die Reihe bekommen.
Tode
-
Naja. Immerhin hat IBM jetzt sowas wie die MaryBethRaven für "Quäl"itätssicherung bei Groupware Produkten im öffentlichen Angebot. Flemming T. Christensen hat ein Blog auf Greenhouse (https://greenhouse.lotus.com/blogs/quality/?lang=de_de). Man soll ja die Hoffnung nie aufgeben. Vielleicht wird es ja doch noch besser mit der Qualität der ausgelieferten Software.
-
Man soll ja die Hoffnung nie aufgeben. Vielleicht wird es ja doch noch besser mit der Qualität der ausgelieferten Software.
Bei allem Respekt: Maureen Leeland machte in Gelsenkirchen auf mich nicht den Eindruck, als sei sie ein Anlass für berechtigte Hoffnung.
Bernhard
-
Bei allem Respekt: Maureen Leeland machte in Gelsenkirchen auf mich nicht den Eindruck, als sei sie ein Anlass für berechtigte Hoffnung.
Es gibt immer mehrere Möglichkeiten wie Qualität in einer Anwendung erzeugt werden kann. Eine davon ist Qualität von innen. Die andere, und auf die hoffe ich schon ein wenig, ist die Erzeugung von Qualität durch Druck von oben/aussen. Immerhin ist es das erste Mal überhaupt, das man jemanden der bei IBM im Groupware Bereich für QS/QA zuständig ist in dieser Rolle auch ganz öffentlich warnehmen kann.
Und Mary Beth Raven und die Installation ihres UI Teams haben ja in einem anderen Bereich gezeigt, das es durchaus funktionieren kann.