Hi Friedrich, *, 2010/11/5 Friedrich Strohmaier <damokles4-lis...@bits-fritz.de>:
Ich fang mal hinten an: > Ich bin gespannt, wieviel Gesprächsbedarf noch entsteht für ein simples, > vom CMS unabhangiges Verzeichnis innerhalb derselben Subdomain.. ;o)) Willste eins, kriegste eins. Aber den Sinn werde ich doch hinterfragen dürfen... > Christian Lohmaier schrieb: >>2010/11/5 Friedrich Strohmaier <damokles4-lis...@bits-fritz.de>: >>> Christian Lohmaier schrieb: >>>>2010/11/5 Friedrich Strohmaier <damokles4-lis...@bits-fritz.de>: > > [...] > Das darf auch gerne flexibel sein und bei Bedarf umgeschaltet werden > können. Prinzipiell gibt es für live zwei Szenarien: > > 1. Es wird ein Abzug des letzten Releases im Netz vorgehalten - statisch > 2. Es wird der aktuelle Arbeitsstand gezeigt - also ein Abzug von den > devel Inhalten. > > Beide Szenarien haben gute Gründe für und wider. Wir hatten bisher > Variante 2 man sieht, wie es "lebt". Also gab es devel doppelt? > [traffic bei live, einem "doppelten" devel kein Problem weil....] > ich per .htaccess dafür sorgte, dass die beliebtesten > Stücke unbemerkt bei einem Mirror mit dickem Datenschlauch geholt > wurden. Geht weiterhin. > Diese Technik wiederum ist Gift für Tester, die Links testen > wollen Das macht das CMS unnötig (für interne Links, und um die geht es ja, wenn von der Bandbreite die Rede ist) Im CMS können kaputte Dateilinks per Bericht gecheckt werden. > oder ein neues Paket einspielen und immer wieder das Alte > angeboten bekommen oder Schlimmeres. Redirect könnte man per entsprechendem Parameter unterbinden, aber betrifft wenn überhaupt auch nur Dateien ohne Versionsnummer, und das sind in der Regel kleine, bei der sich der Redirekt dann auch kaum auswirken würde. > Nun weiter: > Bisher war jetzt in devel/DVD z.B. der Inhalt so zu sehen, wie er > nachher in das ISO eingebaut wurde 1:1. Jetzt kommt mit dem CMS eine > weitere Instanz dazu, die den Inhalt verwaltet. Das was in das ISO kommt > wird aus diesen Inhalten extrahiert zu einem statischen Abbild > umgewandelt. *Erst dieses* wird dann in das ISO eingebaut. Ja bzw. wird unter static.libreofficebox oder live oder was auch immer gespiegelt. > Ich will auch > bei diesem Zwischenschritt alle Elemente möglichst ungehindert anschauen > können, denn da ist 1:1 drin, was nachher im ISO sein sollte. Das kannste vergessen, denn im cms gibt es kein fertiges HTML auf der platte. Das wird entweder dynamisch erstellt, bzw. durch vorgenerierte Seiten (mit dem StaticPublisher, nicht zu verwchseln mit dem StaticExporter) bedient. Die vorgenerierten Seiten sind genausowenig wie die dyamisch generierten Versionen ein Abbild dessen, was der StaticExporter erstellt. Wenn Du einen 1:1 abzug haben willst, was nacher im ISO landet, mußt Du den StaticExporter nutzen. > Nachdem > unser aller Objekt der Begierde ein *Open*source Produkt ist, will ich > dieses Privileg nicht für mich behalten - ich könnte es ja auf dem > Server anschauen -, Nee - denn auch da wirste nur die assets sehen und die Daten von silverstripe, der Rest ist in der Datenbank. > sondern allen zugänglich machen, die daran Interesse > haben. Es soll also weiterhin ein Verzeichnis geben in dem die > DVD-Inhalte in der Reinform zu betrachten *und zu untersuchen* sind. Gibt es wiegesagt nicht. Nur für die assets - und da macht es in meinen Augen auch keinen unterschied ob ich mir die im CMS anschaue, oder im Browser, aber darüber will ich nicht streiten, das Verzeichnislisting kannste gerne haben :-) (siehe anderes Posting) >>Also Fakt (so wie ich es sehe), das Zeug, zumindest die automatisch >>generierten Sachen wie das Beispiel mit den versionslisten braucht >>nicht im cms-Verzeichnis zu liegen. > > genau! Puh, doch nicht komplett andere Ansichten :-) >>zugänglicher Webspace ist ziemlich schwammig. Du willst die Dateien in >>assets sehen, per apache-Verzeichnis listing. > > Nein, ich will andere Verzeichnisse in devel haben, in denen ich ohne > CMS schalten und walten kann. Aber dann haste noch weniger ein 1:1 mapping - aber wiegesagt: kannste haben. >>>>Naja, ist halt essentiell für das Verständnis der Zusammenhänge :-) > > besser jetzt? :o)) solala. Aber Dir ist es wichtig, also bekommst Du es auch :-) > Du hast natürlich recht: Das Schlüsselproblem ist die Tatsache, dass das > CMS das DocumentRoot in seinem Verzeichnis haben will, Nee, umgekehrt - dem CMS ist es wurscht wo seine Daten liegen, Du willst nur nicht, daß das cms für devel.libreofficebox.org zuständig ist. Aber wie man dann die Inhalte nach devel.libreofficebox.org bekommt ist dann wieder das nächste Problem - eben auch durch das CMS gepflegt, und dann beißt sich die Katze in den Schwanz. > und ich nicht > weiß, ob und wenn wie ich ihm dieses abgewöhnen kann. Hätte ich es > gewusst hätten wir viel Zeit gespart und ich hätte heute statt Mails > geschrieben z.B. die Verzeichnisstruktur für die Medieninhalte > vorbereiten und die Scripte anpassen können. Morgen ist die Zeit wieder > für andere Dinge reserviert und es wird wieder knapp, knapp. Das Problem hab ich immer noch nicht verstanden. Welche sonstigen Medieninhalte? Warum die am CMS-Vorbeischmuggeln? Wenn es um den export in ein "fertiges Verzeichnisabbild, daß als ISO gepackt wird" geht, dann gibts das Skript ja quasi schon. Was da gefehlt hat (kmelon) ist ja schnell hinzugefügt. Das aneinander vorbeireden ist es, was für Verzögerungen sorgt. Dein Arbeitsablauf ist mir immer noch schleierhaft. Hättest Du jetzt nix von weiteren Medieninhalten gesprochen, dann hätte ich gesagt ich habs verstanden, die Tools zum bauen des Isos, etc hättest Du auch gerne in devel, nicht vom cms verwaltet, aber in devel. Aber warum Medieninhalte extra sein sollen - da hörts dann schon wieder auf. >>Und da wären wir wieder bei dem Problem der Frage nach dem Weg, und >>nicht der Beschreibung des Ziels/Zwecks. > > eigentlich war mir heute nicht nach philosophieren sondern nach > arbeiten. Bitte nicht beleidigt sein, aber die Fragen nach dem Muster "ich habe mir folgenden weg ausgedacht, erst hier klicken, dann da klicken, und dann soll am Ende das rauskommen, was ich mir vorgestellt habe" dauern immer länger als Fragen "ich will dies und jenes aus folgenden Gründen haben". >>Für die devel.* soll es nun >>* ein apache-Verzeichnislisting der Dateien in assets geben > > wenn es der Sache dient - das ist nicht, wovon ich spreche.. :o)) Dann müssen wir einen Mediator beauftragen, der zwischen uns beiden übersetzt... > Nein. assets/ ist mir eigentlich egal.. Wozu dann das Beispiel mit dem mozilla-URL, etc? >>* über devel.libreofficebox.org/irgendeineurl soll ein >>"Versionsverzeichnis" erreichbar sein > > genauer: ein Verzeichnis in dem unabhängig vom CMS Inhalte eingestellt > und abgerufen werden können. Verzeichnis ist Verzeichnis, was drin ist ist wurscht. >>* [bitte mit weiteren Anforderungen ergänzen] > > das war's schon. Also nochmal das Resultat dieses Threads: Du willt devel.libreofficebox.org/irgendeinurl das ein apache-Verzeichnislisting des Inhalts eines Ordners auf dem Server anzeigen soll. Mehr nicht? Dann waren es in der Tat seeeh viele Worte um das zu kommunizieren. 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
