Hi Stefan, *, 2010/11/15 Stefan Weigel <stefan.wei...@bildungskreis.org>: > Am 14.11.2010 23:39, schrieb Christian Lohmaier: >> >> Warum die externen Skripte, > > Macht das auch das CMS? Umso besser, also raus mit den Skripten und > durch die entsprechende Funktion des CMS ersetzen, bitte.
Na, nicht durch das CMS selbst, man muß ihm schon sagen, was es tun soll, aber man kann es natürlich um entsprechende Funktionalität erweitern :-) > [...] Da aber für mich nicht erkennbar war, ob da > was kommen wird, und weil aus meiner Sicht die Zeit drängte, habe > ich das externe Skript verbessert und dokumentiert. Ich hab mir das Skript nochmal näher angeschaut (hinsichtlich der Frage, ob jedesmal nach verfügbaren Downloads gesucht wird, was mir sehr mißfällt) - daher die Bitte: Könntest Du das umschreiben, so daß anstattdessen eine von rsync bereitgestellte Liste verwendet wird? Sprich den Parser so umschreiben, daß er die Ausgabe von rsync -r rsync://rsync.documentfoundation.org/tdf-pub/ einliest, und nicht selber auf dem HTTP-Server in den Verzeichnissen sucht? Dann könnte man das ganze nämlich auch entsprechend cachen. http://doc.silverstripe.org/partial-caching sprich <% cached rsynclistchange %> <% control erstelledownloadlsite([defaultlang]) %> [bastle html aus den items des von der funktion zurückgelieferten elemente] <% end_control %> <% end_cached %> (bzgl control: http://doc.silverstripe.org/templates#controls ) Dann würde man sich das Berechnen der verfügbaren Downloads und das Erstellen des entsperchenden HTMLs sparen, bzw. nur dann ausführen müssen, wenn die Funktion "rsynclistchange" entsprechend meldet, daß sich was geändert hat (md5sum o.ä.) bzw. auch eine Überprüfung "warte mndestens 10 Minuten, bevor Du es nochmal probierst" einbauen... Standardsprache kann über die Sprache der Seite bestimmt werden oder falls das für nötig befunden wird auch über ein zusätzliches Auswahlfeld im CMS, oder falls wirklich gewünscht auch per Javascript. (man könnte das CMS auch zusätzlich eine Seite downloadseite/plain erstellen lassen, die alle Links stur in einer Liste aufführt) >> Frage speziell für die Download Seite auf de.test.libreoffice.org - >> braucht es da den Selektor, oder reichen da auch stinknormale Links? > > Was meinst du mit "Selektor"? Meinst Du die Auswahllisten? Wie will > man die Auswahl von 645 sich laufend ändernden Möglichkeiten über > normale Links realisieren? Schon im anderen Thread angeschnitten: Natürlich sollen nicht alle Links aufgelistet werden. Aber wenn man die Daten einmal im CMS hat, kann man damit ja machen, was man will, man kann auch dynamisch entscheiden, was man damit machen will. Sowas wie "ab 10 Elementen oder mehr, mach eine Listbox daraus" oder "bei 30 oder mehr, erstelle mehrere Seiten mit "nächste/vorherige" Links" (für download nicht gerade sinnvoll :-)), oder oder.. >> (bzw. Frage in dieselbe Richtung: Könnte auch wieder in Silverstripe >> direkt implementiert werden - k.A. ob Du die Liste der verfügbaren >> Downloads manuell in Dein Skript einpflegen mußt oder nicht. > > Nein, nein! Das ist doch der Witz. :-) > > <quote> > a PHP script in the background crawls through the download > directories of the server and collects all currently available > download packages > </quote> Ja, aber das zieht die Performance ganz schön runter... das fopen wird wohl kaum die Verbindung für weitere Requests offen halten, sprich für jedes Verzeichnis 'ne komplett neue Anfrage, oder? Aber die Version ist hartcodiert - sowohl in den links als auch in der extra Variable, das müßte dann noch "eleganter" gelöst werden. ciao Christian -- E-Mail to discuss+h...@de.libreoffice.org for instructions on how to unsubscribe List archives are available at http://de.libreoffice.org/lists/discuss/ All messages you send to this list will be publicly archived and cannot be deleted
