Welchen Wert liefert die Funktion IPS_CreateVariable() im Falle, dass die zulässige Anzahl der Variablen der Lizenz überschritten ist / bzw. bei Anlage einer weiteren Variablen würde?
Da ich Setup-Scripte für einige meiner Scripte schreibe, um umständliches Erklären zu ersparen, müsste ich dann diesen Fehler abfangen.
Anregung: IPS_CanCreateVariable() als weitere Funktion. Das würde das schreiben von @IPS_CreateVaraibel (mit @) und dann erst Abfrage, ob das gut ging, erübrigen und es wären stabilere Scripte zu schreiben.
klar würde das gehen. Erstens müsste dann aber - z.B. bei anderen als Setup_scripten mit
@IPS_CreateVariable gearbeitet werden um Fehlerbildschirme a la Webfront zu vermeiden.
Wenn ich mich recht entsinne, hast Du mal geschrieben, dass Du gegen das @ was hast …
zweitens / ausserdem wäre es sinnvoll, wenn man einen etwas GENAUEREN Grund geliefert bekommt, warum die Anlage der Variablen nicht ging. Sonst würde man per Meldung den Benutzer vielleicht in die Irre schicken.
Grundsätzlich könnte das ja (in Zukunft --> Demoversion, weitere/andere Lizenzmodelle) auch andere Gründe haben, oder?
Insofern wäre eine zurückgelieferte Zahl oder ein Text m.E. sicher nicht verkehrt.
Du kannst Variablen anlegen so viele du willst - sobald du über dem Limit bist, kannst du auf diese nur nicht schreiben. Das umgeht dein Problem, dass irgendwelche Installations-Skripte nicht funktionieren. Die meckern nur, dass nicht auf die Variable zugegriffen werden kann.
Da muss ich mal kritsch sein: Das halte ich für keine professionelle Lösung.
Denn so muss ja noch umständlicher abgeprüft werden, ob nun was geht oder nicht. Das ist m.E. total inkonsequent! Entweder ich habe ein Variablenlimit, dann muss ich das auch ordentlich behandeln oder es gibt keins.
Ins besondere, wenn man sich dann noch vorstellt, dass Variablen zur Laufzeit erst angelegt werden oder noch schlimmer, zur Laufzeit dann „nachgezogen werden“, wenn sie nicht mehr exisitieren.
Ich sehe den Tag kommen, wo ein User eine Variable löscht, die schon länger nicht geändert wurde, weil er am Limit ist. Und schwupp hamma bdas Problem.
Ich würde sogar eine weitere Property für Variablen vorschlagen: „non deletable“ - eine solche Variable kann nur nach weiterer Sicherheitsfrage oder per Script gelöscht werden. Das würde das o.g. Problem zu verhindern helfen, wenn zusätzlich ein (individueller) Hinweis gespeichert werden könnte ("Diese Variable wird für xyz benötigt. Wenn Sie die Var löschen, kann es zu Funktionsstörungen kommen.).
Ist mir schon klar, dass ihr da an vielen Stellen an den Code müsst. Aber so ist das, wenn man Lizenzmodelle ändert. Ich hatte das in meinem eigenen Laden auch mal.
Du kannst mit der Property "VariableIsLocked" jederzeit abfragen, ob diese Variable nutzbar ist.
Es wird nichts zur Laufzeit nachgezogen. Wenn du über dem Limit bist und etwas löscht, musst du IPS neu starten, damit diese nicht mehr das „locked“ Flag haben.
Prima. Dann ist die „Funktion“ ja da - man braucht zwar wieder ein Zwischenarray, aber gut … das ist ne PHP-Schwäche.
Das hatte ich wissen wollen - war in der Update-Doku m.W. nicht drin … wäre es nicht eine Zeile wert?
Nochmals zu meiner Anregung zur generellen Propety von Variablen, solche als „systemisch“ oder „vital“ zu kennzeichnen. Da kann vor allem dann Sinn machen, wenn eine Variable „woanders“ im Objektbaum hängt und so ihre Benutzung nicht unmittelbar sichtbar ist.
Und noch eine Anregung: Könntet ihr nicht bei IPS_GetObject einen optionalen zweiten Parameter einführen, mit dem man ein Property direkt bekommt (statt über das assoziative Array gehen zu müssen)?
(Das würde dann für jeden Objekt-Abruf, bei dem ich die Objekt- oder Objekttypeigenschaften kriege, gelten …)