Konzeptionsproblem: Fenster nicht neu laden

[Marc]

Hallo,

ich bastele gerade an einem Downloader-Script. Ich stelle mir das so vor. Die besucher können auf mehreren Seiten Dateien auswählen, die sie herunterladen wollen (Zu jeder datei ein link). In einem neuen fenster wird dann eine Liste geführt, mit allen dateien, die der User schon angeklickt hat und auf Wunsch kann er die dann alle gemeinsam herunterladen. Dieses Liste führen ist auch kein Problem, das fenster aber schon. Irgendwie muss ich es schaffen das Fenster nur einmal zu öffnen. Denn wenn es schon offen ist, und die Liste schon teilweise geführt wird, und dann nochmal der window.open Befehl ausgeführt wird ist die Liste natürlich wieder weg. Als zusätzliches Problem stellt sich noch, das die Downloads (und die entsprechenden links) über mehrere Seiten verteilt sind.
hat irgendwer eine Idee wie ich das ganze konzipieren kann, das das fenster sicher nicht neu geladen wird (also kein window.open, wenn das fenster offen ist) aber geöffnet wird, wenn das fenster noch nicht offen ist, oder der User das fenster geschlossen hat.

grüsse

Marc

[Ben]

Hi Marc,

ich kenne den Aufbau deines Scriptes nicht, aber wenn du das ganze irgendwie mit Links baust, müssten diese als target wohl den Namen des Fensters (vergibst du ja beim window.open) haben.

Viele Grüße
Ben

[Marc]

Moin,

sorry, da habe ich mich schlecht ausgedrückt. Es sind zwar links, diese sprechen aber eine JS funktion an. Mit Links wollte ich eigentlich nur sagen, das ich keine Formulare mit checkboxen oder so nutze...

grüsse

Marc

[Ben]

Hi Marc,

wäre schön wenn du dein Script (oder die wichtigen Teile) mal posten könntest. Versuche dann sehr gern dir zu helfen. :-)

Viele Grüße
Ben

[Marc]

Hi,

gerade eben passiert :)

Grüsse

Marc

[Ben]

Hi Marc,

habe es gesehen. Auch wenn man hier natürlich das PopUp nicht ganz nachvollziehen kann. ;-)

Meiner Meinung nach müsstest du in dem Script überall, wo du document benutzt den Fensternamen davorschreiben. Dann müsste es, soweit ich weiß, auch funktionieren. (Bin aber noch nicht ganz sooo fit in JavaScript!)

Viele Grüße,
Ben

[Marc]

Moin,

hm, das scheint nicht zu klappen...
Name des fensters: dlWin
Meldung: dlWin ist kein Objekt

Grüsse

marc

[Marc]

Als Nachtrag nochmal das dazugehörige Script mit Erklärungen:

http://www.startrekbilder.de/playground/scriptbase.htm

Dieses Script habe ich bisher gebaut und das soll in dem Fenster ablaufen. Die List zeigt die dateien an, die bisher eingetragen wurden (im moment schon mal 6 Stück). Der Link "Test" ist ein test für das hinzufügen, was in dieser Art von den Downloadseiten geschehen soll. Ausserdem wird von dem Script neben der liste noch ein hidden-field manipuliert, das die File-IDs zu den gewünschten dateien enthält (id1|id2|id3 usw.) Das ganze soll später dann an ein PHP_Script übermittelt werden.
Folgende Funktionen habe ich verwendet:
rmfile() - Entfernt die zur Zeit makierte datei aus der Liste
addfile(name, id) - Fügt eine datei in die liste und das hidden-Field hinzu. Die anderen Funktionen sind nicht so wichtig.

Ich hoffe jetzt könnt ihr besser verstehen, wie das ganze laufen soll und wie mein problem aussieht...

[Sven Rautenberg]

Moin!

Ich hoffe jetzt könnt ihr besser verstehen, wie das ganze laufen soll und wie mein problem aussieht...

Ich habe mir deine Seite angesehen und denke, ich weiß, was du machen willst. Grob beschrieben: Du willst dem Benutzer ermöglichen, seine Downloads erstmal vorzuselektieren und dann die Liste vor dem wirklichen Download nochmal durchzusehen.

Dennoch stelle ich dir die Frage: Macht das Sinn? Welchen Vorteil hat es für den Benutzer, dass du hier vom Standard (der ist, dass man nach Klicken auf einen Downloadlink gleich die Datei erhält) abweichst.

Ich will gerne glauben, dass du dir irgendeinen Vorteil ausgedacht hast, den diese Liste bieten soll. Würdest du deine Gedanken mitteilen?

Mir fallen selbst ein paar Dinge ein, die für den Benutzer Vorteile bieten können. Beispielsweise könnte man die gewählten Dateien, die selbst unkomprimiert vorliegen, alle dynamisch in eine ZIP-Datei packen.

Allerdings gebe ich zu bedenken: Die Internet-Verbindung des Benutzers ist beim Surfen und Seiten-Angucken in der Regel nicht besonders ausgelastet - hin und wieder mal eine neue Seite durchlassen, das war's. Insofern empfinde ich deine Idee aus mehreren Gründen als nachteilig für den Nutzer.

1. Wenn der Download sofort startet, kann der Benutzer weiter schmökern - die Leerlaufzeit seiner Leitung wird sinnvoll genutzt. Da nicht jeder eine Flatrate hat, sondern viele noch zeitbasiert surfen (auch mit DSL gibts Zeittarife), ist Zeit also Geld. Je kürzer der Gesamtaufenthalt ist, desto billiger.

2. Bedenke auch, dass es etliche Benutzer gibt, die Downloadtools einsetzen. Diese Tools bauen gerne mehrere parallele Verbindungen zum Server auf und laden unterschiedliche Bereiche der Datei. Dein Downloadskript sollte diese Variante unterstützen. Allerdings ist Support dafür nicht so leicht hinzukriegen - ich wüßte spontan mit PHP nicht, wie das gehen sollte. Es wird vom Webserver bei statischen, als Datei abgelegten Downloads ganz einfach realisiert - bei dynamisch generierten Inhalten ist das schwieriger.

3. Außerdem bieten Browser auch von sich aus an, abgebrochene Downloads fortzusetzen. Diese Funktion ist essentiell für Modem- und ISDN-Benutzer (deshalb auch die Downloadtools). Deine Funktion sollte diese Möglichkeit ebenfalls ermöglichen.

Wenn du all diese Dinge bedacht hast, und wenn du mit deiner Liste eine Funktion anbietest, die darüber hinausgehend noch ultimative (oder auch nur leichte) Vorteile bietet, die die verbleibenden Nachteile aufwiegt, dann realisiere deine Lösung. Ansonsten überlege dir, ob sie wirklich sinnvoll ist.

- Sven Rautenberg

[Ben]

Hi,

ich denke, wenn er das ganze aber als Alternative anbietet ist es z.B. gerade für DSL-User nützlich, die dann nicht alle kleinen Dateien einzeln runterladen müssen, sondern einfach eine Vorauswahl treffen und diese dann auf einmal ziehen können.

Die normale Variante würde ich aber auch lieber anbieten.

Viele Grüße
Ben

[Marc]

Hiho,

ok, ich werde versuchen dir zu erklären wo ich die Vorteile sehe. Ich muss ganz ehrlich sagen ein Grossteil der Vorteile liegt auf meiner Seite, aber ich habe auch versucht die Nachteile so klein wie möglich zu halten.

Ich habe mir deine Seite angesehen und denke, ich weiß, was du machen willst. Grob beschrieben: Du willst dem Benutzer ermöglichen, seine Downloads erstmal vorzuselektieren und dann die Liste vor dem wirklichen Download nochmal durchzusehen.

Da liegt ein Vorteil für mich. Der User überlegt sich noch einmal ob er die dateien wirklich braucht und entscheidet sich vielleicht einige doch nicht zu laden, wenn er merkt wie viel das wird. Das ist ein traffic-Ersparniss für mich.

Wie du gesagt hast ist eine dynamische zip-Datei ein vorteil, den ich nutzen will. Vor allem bei vielen kleinen dateien (um die es hier geht) finde ich es eine grosse zeitersparniss, wenn man alle Dateien gleichzeitig herunterlädt in einer datei, als zig DLs starten zu müssen. Dann kann man später in aller ruhe offline das Archiv entpacken und die Datemn durchsehen.

Ein weiterer Vorteil für mich ist, das die dateien nicht einheitlich benannt sind (bin einfach zu faul dazu). Bei dem zip-Vorgang kann ich für jede Datei einen Namen festelgen mit der sie später im Archiv auftaucht. Dieser Name soll (wenn alles klappt) vom User selber teilweise vergeben werden. Also so nach dem Format: <Kategorie>_<id> wobei vom Script dann die entsprechenden Variablen eingesetzt werden.

Ein weitere Vorteil ist eine Verzeichnissstruktur. Ich habe vor im zip-Archiv (auf Wunsch) die Verzeichnissstruktur auf dem Server nachzubilden. Das heisst wenn der User mehrere dateien aus unterschiedlichen kategorien herunterlädt, dann kann er wahlweise eine Verzeichnisstruktur mitgeliefert bekommen, so das Dateien aus kat1 auch im entsprechenden ordner sind. Sortieren entfällt.

Das die daten komprimiert sind und damit auch noch etwas Platz und traffic gespart wird kommt auch noch hinzu.

1. Wenn der Download sofort startet, kann der Benutzer weiter schmökern - die Leerlaufzeit seiner Leitung wird sinnvoll genutzt. Da nicht jeder eine Flatrate hat, sondern viele noch zeitbasiert surfen (auch mit DSL gibts Zeittarife), ist Zeit also Geld. Je kürzer der Gesamtaufenthalt ist, desto billiger.

Das ist ein berechtigter Einwand. Allerdings gehe ich davon aus, das die Besucher, die es eilig haben einfach die DLs nicht komplett aussuchen, sondern nur einen teil eintragen, diesen DL dann starten und danach eine neue Liste anlegen.

Für DL-Tools habe ich mir auch etwas überlegt. Die dateien werden nicht vom PHP-Script gesendet, sondern in einem temporärem Ordner abgelegt und bleiben dort 24 Stunden liegen. In dieser Zeit kann jeder per DL-Tool herunterladen oder resumen.
In diesem temporärem System liegt ein weiterer Vorteil. Da niemand Zugriff auf die wirklichen Dateien hat ist es nicht möglich, das andere Webmaster unerlaubt meine Dateien mitnutzen und so bei mir Trafic verursachen.

Ich hoffe ich habe alles bedacht und die Vorteile wiegen die Nachteile  auf. ich für meinen teil denke jedenfalls schon, das dies eine sinnvolle Sache ist.

Grüsse

Marc

[Sven Rautenberg]

Moin!

ok, ich werde versuchen dir zu erklären wo ich die Vorteile sehe. Ich muss ganz ehrlich sagen ein Grossteil der Vorteile liegt auf meiner Seite, aber ich habe auch versucht die Nachteile so klein wie möglich zu halten.

Dann nehme ich mal eine pessimistische Position ein und kommentiere. :)

Ich habe mir deine Seite angesehen und denke, ich weiß, was du machen willst. Grob beschrieben: Du willst dem Benutzer ermöglichen, seine Downloads erstmal vorzuselektieren und dann die Liste vor dem wirklichen Download nochmal durchzusehen.

Da liegt ein Vorteil für mich. Der User überlegt sich noch einmal ob er die dateien wirklich braucht und entscheidet sich vielleicht einige doch nicht zu laden, wenn er merkt wie viel das wird. Das ist ein traffic-Ersparniss für mich.

Und für wieviele User gilt das wirklich? Wer einen Download haben will, wird ihn starten. Das Traffic-Argument gilt in jeder Hinsicht nicht für Flatrate-Besitzer (oder solche, die für den Download nichts zahlen, weil das jemand anderes tut), und eher nicht für Benutzer von zeitbasierten Tarifen. Die hoffen nur, dass die Leitung glüht, damit der Download schnell vorbei ist. Lediglich Nutzer eines trafficbasierten Zugangs könnten vielleicht vor dem Download nochmal nachrechnen. Ich persönlich erwarte es aber nicht wirklich.

Wie du gesagt hast ist eine dynamische zip-Datei ein vorteil, den ich nutzen will. Vor allem bei vielen kleinen dateien (um die es hier geht) finde ich es eine grosse zeitersparniss, wenn man alle Dateien gleichzeitig herunterlädt in einer datei, als zig DLs starten zu müssen. Dann kann man später in aller ruhe offline das Archiv entpacken und die Datemn durchsehen.

Diesen Vorteil sehe ich durchaus.

Ein weiterer Vorteil für mich ist, das die dateien nicht einheitlich benannt sind (bin einfach zu faul dazu). Bei dem zip-Vorgang kann ich für jede Datei einen Namen festelgen mit der sie später im Archiv auftaucht. Dieser Name soll (wenn alles klappt) vom User selber teilweise vergeben werden. Also so nach dem Format: <Kategorie>_<id> wobei vom Script dann die entsprechenden Variablen eingesetzt werden.

Die Benennung der Dateien sollte kein Argument sein. Bei normalen Downloads kann der Benutzer den Dateinamen ebenfalls festlegen, und du bist auch nicht gezwungen, eine einheitliche Benennung durchzuführen. Solange die Links zum Download funktionieren, ist alles kein Thema.

Ein weitere Vorteil ist eine Verzeichnissstruktur. Ich habe vor im zip-Archiv (auf Wunsch) die Verzeichnissstruktur auf dem Server nachzubilden. Das heisst wenn der User mehrere dateien aus unterschiedlichen kategorien herunterlädt, dann kann er wahlweise eine Verzeichnisstruktur mitgeliefert bekommen, so das Dateien aus kat1 auch im entsprechenden ordner sind. Sortieren entfällt.

Ok, ein kleiner Vorteil für den Benutzer (aber wirklich nur sehr klein). Ich lege üblicherweise beim Speichern evtl. gewünschte Unterverzeichnisse an oder lasse es sein. Geschieht automatisch beim Download-Ziel-Wählen.

Das die daten komprimiert sind und damit auch noch etwas Platz und traffic gespart wird kommt auch noch hinzu.

Naja, es ist ja nun kein Thema, entweder die Dateien alle gezippt auf den Server zu packen oder wahlweise den Server die Komprimierung übernehmen zu lassen. mod_gzip bzw. gzip_cnc lassen grüßen. Und auch PHP liefert Mechanismen mit. Wenn du Traffic sparen willst, solltest du dir lieber über die komprimierte Auslieferung der HTML-Seiten Gedanken machen. Da lassen sich traumhafte Quoten erzielen. Hier im Forum wird die Startseite auf ein Zehntel ihrer unkomprimierten Größe gebracht.

1. Wenn der Download sofort startet, kann der Benutzer weiter schmökern - die Leerlaufzeit seiner Leitung wird sinnvoll genutzt. Da nicht jeder eine Flatrate hat, sondern viele noch zeitbasiert surfen (auch mit DSL gibts Zeittarife), ist Zeit also Geld. Je kürzer der Gesamtaufenthalt ist, desto billiger.

Das ist ein berechtigter Einwand. Allerdings gehe ich davon aus, das die Besucher, die es eilig haben einfach die DLs nicht komplett aussuchen, sondern nur einen teil eintragen, diesen DL dann starten und danach eine neue Liste anlegen.

Dann gehen deine gesamten Vorteile, die du dir so mühsam erarbeitet hast, aber wieder flöten.

Für DL-Tools habe ich mir auch etwas überlegt. Die dateien werden nicht vom PHP-Script gesendet, sondern in einem temporärem Ordner abgelegt und bleiben dort 24 Stunden liegen. In dieser Zeit kann jeder per DL-Tool herunterladen oder resumen.

Ok, das dürfte helfen. Allerdings brauchst du dafür natürlich Speicherplatz, den du andernfalls nicht benötigen würdest.

In diesem temporärem System liegt ein weiterer Vorteil. Da niemand Zugriff auf die wirklichen Dateien hat ist es nicht möglich, das andere Webmaster unerlaubt meine Dateien mitnutzen und so bei mir Trafic verursachen.

Es ist uninteressant, wo die Originaldaten liegen, solange der Mechanismus, der die Daten liefert, dazu veranlaßt werden kann, die Daten über eine URL zur Verfügung zu stellen. Die Downloadtools brauchen ja schließlich auch eine URL, um dranzukommen, und der Server musste vorher veranlaßt werden, diese URL gültig zu machen. Das kann man nachbauen - was sich zugegebenermaßen nur lohnt, wenn andere wirklich Interesse dran haben, es zu umgehen.

Ich hoffe ich habe alles bedacht und die Vorteile wiegen die Nachteile  auf. ich für meinen teil denke jedenfalls schon, das dies eine sinnvolle Sache ist.

Naja - funktionieren muß es natürlich.

- Sven Rautenberg

[Struppi]

Als Nachtrag nochmal das dazugehörige Script mit Erklärungen:

http://www.startrekbilder.de/playground/scriptbase.htm

:-(

Not Found

The requested URL /playground/startrekarchiv.css was not found on this server.

Struppi.

[Marc]

Sorry, hab vergessen die css-Datei mit hochzuladen... Ist jetzt aber nachgeholt!

Grüsse

Marc