Filenamen nicht umbenennen?

IPS bietet die Möglichkeit, via Eigenschaften (im Script-Editor) dem Script einen eigenen Namen zu vergeben. Das kann man sowohl bei neu anzulegenden Scripts tun als auch nachträglich bei bestehenden ändern. Im Forum sieht man das immer gut in bereit gestellten Projekten, wenn Scripte includes enthalten:

 

 

Auch hier will ich nicht soweit gehen und meine Ansicht als Maßstab ansetzen (auch wenn dieser Artikel von einem etwas restritiven Artikelbild illustriert wurde), aber das Umbenennen der Files hat aus meiner Sicht mehr Nach- als Vorteile. Und ich habe mich dazu entschieden, das Datei-Management, was IP-Symcon mitbringt, auch vollständig IP-Symcon zu überlassen. Ich hatte damit in den verg. 2 Jahren nie ein Problem. Und ich hab mir schon öfter in den A***** gebissen, weil mir der Scriptname, den ich selbst vor Monaten vergeben hatte, nicht mehr einfiel und ich mich dumm und dämlich gesucht habe. Oder zum Beispiel dann, wenn ein Systemlog das Script als fehlerhaft ausweist und statt Script-ID der Scriptname im Logfile steht => man hat keine Chance, dieses Script im Objektbaum über die Suche zu finden.

Ab und zu schaue ich doch mal direkt in den Scriptordner und staune über etliche benamste Scripte – von denen ich natürlich keine Ahnung habe, wo die her kommen, zu welchem Projekt die gehören und 

Nachteile

  • sucht man im Objektbaum nach einem Script (über die IPS-Konsolenfunktion „SucheID), geht dies ausschließlich nur mit ID’s. Ein manuell (um-)benanntes Script kann mit der ID-Suche der Konsole so nicht gefunden werden
  • manuell (um-)benannte Scripte werden von IPS nach dem Löschen aus dem IPS-Objektbaum nicht immer aus dem Dateiordner entfernt (in einigen Systemen klappt es, in anderen nicht, in wieder anderen nur sporadisch)
  • ein im Dateiordner identifiziertes Script lässt sich nur via ID im Objektbaum wiederfinden
  • in Logs fehlerhaft aufgeführte Scripte lassen sich ebenfalls nicht einfach wieder finden
  • includierte Scripte lassen sich via IPS Objektbaum nicht auffinden
  • benamste Scripte sind nicht zwingend unique: hat man mehrere Fremdprojekte im System, kann es durchaus passieren, dass in mehr als einem Projekt der selbe Scriptname benutzt wird – aber unterschiedlichen Code enthält. Beliebtes Beispiel ist „functions.ips.php“. Das jeweils zuletzt installierte Projekt wird natürlich funktionieren….

Vorteile

  • für Projekt-Programmierer auf den ersten Blick leichter zu händeln: sprechende Namen sind leichter zu merken
  • arbeitet man (auch) im Dateisystem, lassen sich die Scripte leichter identifizieren

Sicher könnte man daraus einen Glaubenskrieg machen. Ich denke, hier muss jeder für sich entscheiden, wie er damit umgeht. Ich habe mittlerweile über 800 Scripte im Objektbaum. Probleme hatte ich -in diesem Kontext- bisher ausschließlich mit manuell benannten Scripts.

Und ich habe kürzlich Zeitgenossen erlebt, die im IPS-Scriptordner noch aufwändige Filestrukturen (pro Projekt ein Ordner, der alle projektrelevanten Scripte enthält) etablieren. Meiner Meinung nach ist das unnötiger Aufwand (wie schon erwähnt: IPS bringt ein eigenes, sehr verlässliches Filemanagement mit), der früher oder später zu Problemen führen wird. Ich möchte mich in diesem Kontext um das Kernthema kümmern: die Automation, nicht um das File-Management.

Zu guter Letzt ist das auch von Vorteil, wenn man mit dem Project Exporter Projekte kopieren will: eine ID (im Scriptnamen) ist einfach flexibler und sicherer zu handeln als ein umbenanntes Script. Zum Beispiel, wenn man ein Projekt im Quell-System vervielfältigen will….. mit ID’s im Scriptnamen kein Problem. Denn die Hoheit über die ID-Vergabe  hat immer das lokale IP-Symcon. Damit ist garantiert, dass neu installierte Scripte immer unique sind.

Bei benamsten Scripten kann das problematisch werden: befindet sich schon eine „functions.ips.php“ (z.B. aus einem anderen Fremdprojekt) im System (u.U. weiß der User gar nichts davon), wird die „functions.ips.php“ aus dem neuen Projekt entweder gar nicht installiert oder das Install-Script überschreibt die bestehende „functions.ips.php“ mit der Neuen (je nach gewählter Funktion im Installscript). Viel Spaß bei der Fehlersuche im Fremdprojekt (wenn man Glück hat, bemerkt man das Problem im Fremdprojekt kurz nach Installation des neuen Projekts und kann evtl. so noch die Ursache zuordnen). Und hier ist es eigentlich egal, ob die (Fremd-)Projekte via Project Exporter/Installer installiert werden oder durch eine Installationsroutine, die der Programmautor selbst geschrieben hat….

In diesem Sinne…. ;-)

 

 

 


Getagged mit
 

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

css.php