MDFL - alle individuellen Rahmen sind überschrieben

[kuni-r]

Hallo Leute,

eben wollte ich auf meine mühevoll für den MFDL erstellten Rahmen zugreifen und stellte mit großer Bestürzung fest, daß irgend ein Zeitgenosse, der es vermutlich gut gemeint hat, fertige Rahmen in einer MFDL.TXT beigepackt und eingestellt hat, daß diese MFDL.TXT ohne Rückmeldung und ohne jegliche Information bei der Beta-Installation von FF überschrieben wird.

Ich bitte dringend, so was nie wieder zu machen! Ich war stinkesauer. Gottseidank hatte ich noch eine ältere FF-Version mit meinen eigenen Rahmen auf dem Notebook.

Wenn ich was nicht leiden kann, dann sind das Programme, die sich oder irgendwas von sich selbstständig installieren und Dateien einfach ohne Rückfrage überschreiben. Ich möchte gefälligst selbst bestimmen, ob ich das will oder nicht.

 

[hhoefling]

Stimmt, ist mir garnicht aufgefallen da ich meine Rahmen gar nicht vermisst habe ;-)

Aber hier ist zumindest eine Rückfrage des Installationsprogramms nötig!

 

[Hippo6]

Ich bitte dringend, so was nie wieder zu machen! Ich war stinkesauer. Gottseidank hatte ich noch eine ältere FF-Version mit meinen eigenen Rahmen auf dem Notebook.

Hattest du deine Rahmen nicht gespendet....?
Wie unsozial. Ich glaub das war der Racheengel.

Im Ernst, ich wäre auch sauer gewesen. Wenn man selbst Fehler macht, die solch ein Ergebnis produzieren, dann ist das was anderes. Aber wenn jemand anderes Löschpapier anlegt, dann frisst das ganz schön. Ich kann das verstehen, da du auch feine Rahmen hattest.
Tust mir leid.
Aber vielen Dank für die Warnung
Ich bin in letzter Zeit nicht mehr ganz so aktuell.

 

[JKS]

V2.75 B70: automatische Skriptinstallation überschreibt keine Dateien mehr.

 

[W.P.]

Hallo J.K.,

ob das so gut ist? Wie kann man dann ein Update einspielen ohne vorher alle Script-Dateien zu löschen.
Es gibt Leutchen die bringen es fertig und löschen die halbe Installation, wenn sie nur ein paar Dateien zu löschen haben. Nicht jeder hat den Einblick, wie weit er gehen darf.

Ich bin mehr dafür, ungesehen der neuen Beta, dass das Script entsprechend angepasst wird und die mitgelieferten Rahmen- und Konfigurationsdateien das Anhängsel *.upd bekommen. Beim ersten Start vom MFDL wird diese *.upd-Datei in die bestehenden Dateien eingepflegt oder, sofern nicht vorhanden, erzeugt. Anschließend wird die *.upd automatisch gelöscht. So bleiben alle alten Daten erhalten, während das Programm erneuert wird.
Diesen Weg pflege ich schon seit der Anfangsphase des HTML-Generators und bin gut damit gefahren.

Schönen Gruß,

Werner.

 

[Hippo6]

Hallo J.K.,

ob das so gut ist? Wie kann man dann ein Update einspielen ohne vorher alle Script-Dateien zu löschen.
Es gibt Leutchen die bringen es fertig und löschen die halbe Installation, wenn sie nur ein paar Dateien zu löschen haben. Nicht jeder hat den Einblick, wie weit er gehen darf.

Ich bin mehr dafür, ungesehen der neuen Beta, dass das Script entsprechend angepasst wird und die mitgelieferten Rahmen- und Konfigurationsdateien das Anhängsel *.upd bekommen. Beim ersten Start vom MFDL wird diese *.upd-Datei in die bestehenden Dateien eingepflegt oder, sofern nicht vorhanden, erzeugt. Anschließend wird die *.upd automatisch gelöscht. So bleiben alle alten Daten erhalten, während das Programm erneuert wird.
Diesen Weg pflege ich schon seit der Anfangsphase des HTML-Generators und bin gut damit gefahren.

Schönen Gruß,

Werner.

Moin Werner,

ich bin eher dafür, dass die Installation einschließlich Scripte automatisch abläuft, evtl. mit einer Auswahl zwischen Voll-, Teil- und Benutzer-Installation mit Riskobelehrung.
In Benutzer-sensiblen Verzeichnissen, wie 'Script', sollten vorgefundene Dateien dagegen als *.bck gesichert werden, damit die angefassten Dateien kenntlich werden und vom Benutzer gecheckt/manuell übertragen werden können.
Die alten Hasen kriegen ihre Rahmen doch wieder rein.

Es fängt aber auch an, anstrengend zu werden. Wer wird denn nach jeder Neu-BETA-Installation anfangen die Rahmen durchzusortieren. Und ja keinen Umbenennen oder patchen. Wie will Joachim sowas verifizieren und patchen/erhalten.

Da bin ich jetzt doch langsam für eine Unterscheidung zwischen 'FF' und 'Eigene' -Rahmen= zwei Batch-Texte. Ich glaub ich leg mir jetzt ein 'Script2' an, um nach Bedarf wechseln zu können. Einfach das Verzeichnis umbenennen

Vielleicht ist das Ganze aber auch nur ein temporäres Problem. Wenn die Rahmen im Umfang künftig nicht mehr erweitert werden, bleibt ja wieder alles stehen...
Immer noch auf Build 59 8)

 

[m.s]

hallo,

warum nicht einfach ne andere textdatei (mfdl-rahmen.txt) als speicherort für die eigenen rahmen nehmen?
müsste natürlich vom mfdl unterstützt werden.

grüsse
micha

 

[Hippo6]

hallo,

warum nicht einfach ne andere textdatei (mfdl-rahmen.txt) als speicherort für die eigenen rahmen nehmen?
müsste natürlich vom mfdl unterstützt werden.

grüsse
micha

Ich halte mich immer ein wenig unabhängig vom Entwickler auf...

Aber wenn Joachim den MFDL umbauen will, hab ich nichts dagegen.
- mfdl.txt
- mfdl_eigene.txt
dienen als Quelle für die Listbox (getrennt oder gemischt).
Der Editor liest und schreibt mfdl_eigene.txt.

...oder schreibt in die in der Listbox geöffnete Sammlung, obwohl... das ist schon wieder Quatsch und fördert, dass falsch gesammelt und bei Überschreiben gemeckert wird.

Sauber trennen!

 

[W.P.]

Hallo hippo6,

...ich bin eher dafür, dass die Installation einschließlich Scripte automatisch abläuft...

genau das wird damit erzielt. Die Update-Maschinerie der Scripteigenen Konfigurationsdateien sollte meiner Meinung nach nur das Script selbst übernehmen. FF kann und darf keine eierlegende Wollmilchsau werden. Es ist schon ein großes Entgegenkommen, die Automatikinstallation überhaupt einzuführen.

Bei meinem Vorschlag wird auch nichts umsortiert. Wenn ein Eintrag in der mfdl.txt vorhanden ist, dann wird er nicht überschrieben. Somit bleiben alte Daten erhalten, sogar in der richtigen Reihenfolge, und neue kommen evtuell hinzu. Kein Löschen, kein unnötiges Backup (es sei denn beim ersten Start nach der Installation wird es gewünscht) etc. . Da Patch-Dateien beim Start-Update(durch MFDL) gelöscht werden, weiß das Programm (MFDL), wann es das erste Mal gestartet wird, um das Scriptinterne Update durchzuführen.

Daher braucht der Endbenutzer nicht mal denken, er macht einfach weiter wie bisher... mit vielleicht ein paar Rahmen mehr. Je mehr der Benutzer gefordert wird, um so mehr kann er falsch machen. Von 100 sind garantiert 5 dabei, die das meckern anfangen werden.

Schönen Gruß,

Werner.

 

[Hippo6]

Bei meinem Vorschlag wird auch nichts umsortiert. Wenn ein Eintrag in der mfdl.txt vorhanden ist, dann wird er nicht überschrieben. Somit bleiben alte Daten erhalten, sogar in der richtigen Reihenfolge, und neue kommen evtuell hinzu. Kein Löschen, kein unnötiges Backup (es sei denn beim ersten Start nach der Installation wird es gewünscht) etc. . Da Patch-Dateien beim Start-Update(durch MFDL) gelöscht werden, weiß das Programm (MFDL), wann es das erste Mal gestartet wird, um das Scriptinterne Update durchzuführen.

Dein Vorschlag ist sicher richtig und optimal.
Ich habe nur kein Vertrauen in die Update-Routine und bin skeptisch.
Was löst denn den Überschreib-Schutz aus?
- #Rahmenname/-überschrift?
- Parameter der Batchanweisung?

Ich bin sicher, dass zukünftig mehr auf vorhandene Rahmen zurückgegriffen wird, die dann einfach geändert/angepasst/zurückgespeichert werden, ohne dass ein neuer Name verpasst wird... Das neue Angebot wird einfach dafür sorgen, dass ich mir was suche, was nur noch angepasst wird. Es gilt also künftig, Anpassungen zu schützen und nicht Kunis' neue Rahmen.
Uups, die latürnich auch

 

[W.P.]

Hallo Eike,

sorry, wenn ich Dir widerspreche.
Das individuelle Update der Rahmendateien und MFDL-Konfigurationsdateien ist nicht Sache von FF sondern vom MFDL.

Du siehst momentan nur den Rahmengenerator. Ich sehe auch noch andere Skripte, die momentan nur runtergeladen und in das Scriptverzeichnis geschoben werden. Ob Kalenderupdates, die vor Weihnachten im Stundentakt kamen oder verschiedene andere Skripte, bei denen es Updates gibt und gab.
Stell Dir vor, Du bist Laie und holst Dir alle diese Updates. Dann musst Du IMMER vorher die alte Version löschen, bevor Du Autokonfiguration drückst. Nun können dort AUCH individuelle Daten gespeichert sein. Wie soll der User entscheiden, welche Daten er löschen darf und welche NICHT. Vergisst er aber einmal, dass die alte Version gelöscht werden muss und meint durch kopieren und Autokonfiguration ist das neue Update installiert, ist er im Irrtum. Wenn er es noch spannt, ist er noch gut beraten. Im Pechfall moniert er, dass der Fehler noch nicht behoben, oder die neue Funktion nicht finden kann. Was dann? -> Seitenlange Dialoge im Forum können die Folge sein, bis einer spannt: "He, Du musst die alte Version erst löschen!"
Ich finde, das ist keine saubere Programmierung und macht nur Ärger. Jeder Programmierer soll für seine Daten selbst verantwortlich sein. Nicht generell alles auf Joachim schieben, und über FF regeln. Dass er der Autor von MFDL ist, ist eine andere Geschichte.

Ich habe nur kein Vertrauen in die Update-Routine und bin skeptisch.

Du wirst der Update-Routine so oder so vertrauen müssen. Sie wird aller Wahrscheinlichkeit von Joachim stammen, oder vertraust Du dem Autor von FF nicht?

Schönen Gruß,

Werner.

 

[Hippo6]

Moin Werner,

bisher war ich davon ausgegangen, dass du klare Vorstellungen davon hast, wie die Update-Routine im Falle des MFDL zu arbeiten hat...

Natürlich habe ich immer das Update von FF im Auge und was dabei im Script-Ordner passiert. Das war ja schließlich auch der Ausgangpunkt für Kunis Aufschrei. Ich gehe davon aus, dass mit dem FF-Update die 300 neuen Rahmen als mfdl.txt geliefert und bei Installation der FF-BETA ohne Rückfrage in den Script-Ordner kopiert wurde, wo die von Kuni gesammelten und in mfdl(_eigen).text als Datei überschrieben und ins Nirvana geschickt wurden. Das ist nicht passiert, weil Kuni die AutoKonfig angeworfen hat, sondern Joachim erstmals was fertiges mitgeliefert hat, was sonst vom MFDL nach AutoKonfig blank neu angelegt wird.

Da das letztlich in Joachims Verantwortlichkeit liegt, überlasse ich es auch ihm, darüber zu entscheiden, ob Korrekturen am MFDL oder der Install-Routine von FF (ggf. einschließlich der Scripting_AutoKonfig-Routine) notwendig sind.
Ich persönlich halte das angesichts der zwei Scripte, die Joachim zur Zeit mitliefert, inzwischen für unnötig, weil dieses temporäre Problem durch ein Umbenennen der vorhandenen mfdl.txt nach mfdl_eigen.bck (o. ä.) und einen entsprechenden Hinweis in der Anleitung zu lösen wäre.

Langfristig, da gebe ich dir Recht, sind Routinen erforderlich, die den User-bezogenen Script-Bereich vor derartigen Unfällen schützen. Joachim muss sich bei Operationen im Script-Bereich halt nur den User-Hut aufsetzen und den Entwickler fragen, was erforderlich ist. Ein wenig Forum-Brainstorming (was passiert wenn...) vor der Neuerung hätte in diesem Fall vielleicht nicht geschadet. Aber ich glaube, dass er da lernfähig ist und sich schon daran erinnert hat, dass er mit dem MFDL nur eine Schnittstelle von FF benutzt, die der Entwickler als Spielwiese für die User geschaffen hat, damit er von lästigen Erweiterungsanfragen befreit wird. ;D 8)

 

[wolboe]

Hallo,

kurzgefaßt: bin ich für den Weg, daß der Anwender unter- und entscheiden kann, ob er die Rahmen aus "Meine_Rahmen.txt" oder "Fremde_Rahmen.txt" oder "MFDL.txt" lädt - das hätte auch den Vorteil, daß man nach eigenen Kriterien in einzelnen *.txt vorsortieren kann, welche Rahmenart man laden will.
Es sollte also die Möglichkeit geben, zwischen verschiedenen Rahmen.txt - Dateien auswählen zu können.

Gruß Wolfgang

 

[talmida]

hallo,

verschiedene Rahmen.txt fände ich sehr gut.
Ich hab leider auch alle meine Rahmen verloren durch das Überschreiben und natürlich hatte ich sie nicht gesichert :.
Jetzt hab ich schon wieder etliche und mehrere Rahmendateien würden den Überblick immens erleichtern.


liebe Grüße
Christa

 

[Hippo6]

Die Möglichkeit seine Rahmen in mehrere Sammlungen zu sortieren hat auch wieder was.
Ich hab mir das Script darauf nochmal angesehen und denke, dass es für Joachim gar nicht so aufwendig sein dürfte das Script dafür anzupassen.
Es fehlt z. Z. einfach nur der Platz in der Dialogbox, aber ich könnte mir vorstellen, dass von der Listbox unten rechts dafür etwas Fläche für den notwendigen Dialog geklaut werden könnte.

 

[W.P.]

Hallo Joachim,

Deine Meinung dazu? Wird sich nochmal was ändern?

Schönen Gruß,
Werner.

 

[JKS]

Hab' noch keine Meinung. Dateiauswahl klingt verlockend (einfach), löst aber das Problem nicht wirklich.