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
