Date: prev next · Thread: first prev next last
2010 Archives by date, by thread · List index


Hi Friedrich, *,

2010/11/5 Friedrich Strohmaier <damokles4-listen@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-listen@bits-fritz.de>:
Christian Lohmaier schrieb:
2010/11/5 Friedrich Strohmaier <damokles4-listen@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+help@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

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.