Archiv verlassen und diese Seite im Standarddesign anzeigen : Infosever - Ein Alternativer Ansatz?
<body>
<center>
< !-- --></center>
<table CELLPADDING=5 >
<tr>
<td WIDTH="20%"></td>
</tr>
<tr>
<td VALIGN=TOP><form action="eingabe.phtml" method=post>
Ihr Benuzer Name: <input name="UserName" value="meinName">Ihr Passwort <input type=password size=12 maxlength=12 name="passwort"value="geheim">
<input type=hidden name="U1" value="Die Ueberschrift">
<input type=hidden name="weitere kürzel" value=" - bisherige Eingaben">< !-- werden hier in Variablen gespeichert Alles was bisher eingegeben wurde
muß so gespeichert da nur die form daten an den server übertragen werden -->
<hr>
<hr>
<table CELLPADDING=5 >
<tr VALIGN=TOP> < !-- diese Buttons müssen mit unterschiedlichen href gefüllt werden! -->
<td WIDTH="20%">[<a href="insert">ins</a>][<a href="edit">edit</a>][<a href="delete">del</a>]
</td>
<td width=80%><font color="#FF0000"><font size=+1>Hier steht alles was bisher eingegeben wurde</font></font>
im wysiwyg
</tr></td></table>
<table CELLPADDING=5 >
<tr VALIGN=TOP>
<td width=20%>[<a href="insert">ins</a>][<a href="edit">edit</a>][<a href="delete">del</a>]
</td>
<td with=80%>Hier steht der zweite Abschnitt der bisher eingegeben wurde
</td>
</tr>
</table>
< !--Toolbar alt
<hr>Toolbar [<a href="abschnitt">Enter</a>] [<a href="tab">Tabelle</a>]
[<a href="shellcommand">Befehl</a>] [<a href="haedline">Überschrift</a>]
[<a href="link">link</a>] [<a href="indexeintrag">index</a>] -->
<hr>
Toolbar: als was ist die Eingabe zu verwenden
<input type=radio name="aktabsatz" value="U1"> U1
<input type=radio name="aktabsatz" value="Visa"> U2
<input type=radio name="aktabsatz" value="shellcomand"> comand
<input type=radio name="aktabsatz" value="punktliste"> Punktliste
<input type=radio name="aktabsatz" value="tabelle"> Tabelle
<input type=radio name="aktabsatz" value="beispiel"> Beispiel
<input type=radio name="aktabsatz" value="index"> indexeintrag
<input type=radio name="aktabsatz" checked value="beschreibung"> Beschreibung
<hr>< !--Ende Toolbar -->
<table CELLPADDING=5 >
<tr VALIGN=TOP>
<td WIDTH="20%">
< !--[<a href="abschnitt">weiter</a>] </td>-->
<input type=button value="Weiter" onClick="weiter">
<td WIDTH="80%"><font color="#000099">Texteingabe: Der aktuell zu
bearbeitende Abschnitt</font>
<textarea name="beitrag" rows=15 cols=80 wrap=VIRTUAL></textarea></td>
</tr>
</table>
<hr>
<table CELLPADDING=5 >
<tr VALIGN=TOP>
<td WIDTH="20%">[<a href="insert">ins</a>][<a href="edit">edit</a>][<a href="delete">del</a>] </td>
<td WIDTH="80%"><font color="#FF0000"><font size=+1>Hier kann auch schon was stehen was bisher eingegeben wurde</font></font>
in wysiwyg</td>
</tr>
</table>
<hr><hr>
<input type="SUBMIT" value="Fertig!">
</p>
< !-- ? der Autor bin ich doch selber !
e-mail an:</font>
<input type=button value="Autor" name="mailanautor">
<input type=button value="Lektor" name="mailanlektor">
wozu an mich eine E-mail? -->
</form>
< !-- --></td>
</tr>
<tr>
<td></td>
</tr>
</table>
</body>
Hallo
Nicht jeder Browser kann Javascript ausführen und hinter wwwoffle läuft bei mir auch mit Netscape dieses Skript im offline modus nicht (mein konfig - problem?)
zwar ist die Eingabemaske schon abgehakt - ein Etappensieg gefeiert - Das gelbe Trikot steht Dir gut Blackbird http://www.linuxinfoserver.de/ubb/smile.gif - dammit meine Gedanken nicht völlig sinnlos waren möchte ich hier versuchten mein "Konzept" wenigstens ansatzweise darzulegen:
Die Eingabemaske wird durch ein CGI Skript generiert. Nachdem das Thema ausgewählt ist schickt dieses Skript ein HTML an den Browser das so ähnlich aussieht wie das obige.
Das eigendliche Eingabefeld "wandert" so durch die neu erstellte Site. Die eingegebenen Daten werden in Variablen gespeichert z.Teil type=hidden und zwar jene die zur Zeit nicht in dem Eingabefeld sichtbar sind
<input type=hidden name="U1" value="Die Ueberschrift">
<input type=hidden name="weitere kürzel" value=" - bisherige Eingaben">
Diese und mehr Daten werden bei jeder Aktion z.B. klick auf "weiter" zum Server geschickt wo sie im Skript als neu formatierte Site generiert werden und wieder zum Client übertragen werden.
So kann man ganz einfach z.B. die Tabellendaten eingeben tab = spalte enter = zeile ; und anschließend sofort sehen ob die Daten richtig formatiert wurden.
Will man einen internen Link setzen so kann der Server so auch eine Auswahliste generieren mit der man das linkziel suchen kann; der Button hier zu fehlt allerdings noch.
Die Toolbar ist noch nicht vollständig; könnte auch durch gif's ersetzt werden und sollte je nach aktuellem Bearbeitungsabschnitt mit sinnvollen buttons gefüllt werden
Auf den meisten Linuxdistributionen läuft der Apache ohnehin, also kann man das CGI nach /usr/local/httpd/cgi-bin/ kopieren und schon läuft das ganze offline auf dem localhost
Das Teil wäre auch gut geeignet um Sites zu korrigieren. Bei der Neuerstellung kann es jedoch sinnvoll sein zwei solche Toolbar/Eingabemasken übereinander zu setzen, das spart mal ein bischen trafic.
Diese Site wird wie gesagt von einem Cgi Skript erzeugt (ihr werdet´s wissen) es ist erforderlich die Tags zu löschen die in die Maske eingegeben wurden; die meisten 'kürzel' sind heirmit wohl auch unnötig - Wir wollen doch auch nicht eine eigene Programmiersprache schreiben
Die Daten kommen also nach klick auf "Fertig" via post in Variablen daher - ohne Formatierung. Jetzt hat man zwei Möglichkeiten:
Die Daten in einer DB speichern
Eine HTML Site generieren und diese speichern
ist gut jetzt
Hallo Robert!
Vielen Dank für Deine Einführung und Nachhilfe in PERL
Gruß Manfred
Was ist jetzt passiert? sind die Cgi Skripts auf dem infoserver auch nicht ganz fehlerfrei? offenbar sind es die kommentare die einen Fehler verursacht haben,löschen oder verändern kann ich den Beitrag nicht mehr - Die Maske kommt auch nicht besonders gut rüber
Blackbird: Darf ich es Dir per email schicken?
hi manfred!
ob du mir das per mail schicken darfst? abba na immer doch! blackbird@dumdidum.de
dachte dass die schon hinreichend bekannt wäre http://www.linuxinfoserver.de/ubb/wink.gif
grüsse blackbird
Hi Manfred
> dammit meine Gedanken nicht völlig sinnlos waren
Das glaubst Du doch selbst nicht http://www.linuxinfoserver.de/ubb/biggrin.gif ? Ab Deiner mail haben Deine leckeren Ideen massgeblich die Struktur der Ausarbeitungen mitgeformt. Zu Deinen letzten Vorschlägen hatte ich noch mal zusammengefasst, was mAn nicht so realisierbar sein dürfte. Bisher hat niemand dargestellt, wie es doch machbar sein könnte. Ergo hab ich versucht, im Script Forum die aktive Phase zu starten. Nur anhand eines konkreten Konzeptes lassen sich die Scripten sinnvoll ausarbeiten. Man muss sich ja an was konkretem orientieren, um den Scripten die Richtung geben zu können.
Deine jetzige Idee kann immer noch realisiert werden - vielleicht ist auch ein Weg sinnvoll, der zwischen beiden Konzepten liegt?
Einen Punkt scheinst Du jetzt nicht beachtet zu haben: Die Eingabe vie e-mail.
> Wir wollen doch auch nicht eine eigene Programmiersprache schreiben
Nö. Die e-mail ist aber zunächst ein leeres Blatt Papier. Der Autor gibt seinen Text "am Stück" ein. Einheitliche Formatanweisungen können am einfachsten mitgegeben werden, wenn die einfachen Kürzel-Tags verwendet werden. Eine Alternative wäre, die ausgefüllte Maske anzuhängen (aber das wird gar nicht funktionieren. Oder gibt es einen Weg, Eingabetext in der Form selbst zu speichern?).
Das jetzige Vorgehen wäre für beide Eingabewege (Form und mail) geeignet. Die Scripten werden für einen Eingabeweg geschrieben. Nach Änderung des Einlese-Auftrags wären sie für beide Wege einsetzbar. Wenn diese Steuerung in einem separaten file vorgenommen wird, braucht das Scriptwerk nicht mal kopiert zu werden. Ist es nicht?
> Auf den meisten Linuxdistributionen läuft der Apache ohnehin, also kann man das CGI nach
> /usr/local/httpd/cgi-bin/ kopieren und schon läuft das ganze offline auf dem localhost
Apache kenn ich als reinen NewsReader. Da alles, was ich besuche, HTML-basiert ist, hätte ich für ihn keine Verwendung. Warumm ihn also installieren? Die CGI's würden doch aber sicher nicht an das Vorhandensein von Apache gebunden sein. Eine globale Pfadangabe zu den CGI's sollte genügen. Deine Idee kommt also prima für alle, die sich die CGI laden wollen http://www.linuxinfoserver.de/ubb/biggrin.gif .
> und zwar jene die zur Zeit nicht in dem Eingabefeld sichtbar sind
Warum lässt Du nicht alle Bestandteile der Eingabe gleichzeitig in Eingabefeldern sichtbar und Verfügbar sein? Wenn wir diesen Weg konsequent ausarbeiten (und auf e-mail-Eingabe verzichten), Wird die Gestaltung der CGI wesentlich einfacher sein können. Das Knobeln lohnt sich also.
Ein paar Fragen:
Welchen Zweck erfüllen zwei Masken?
Wie wird ein Linkziel (zB. auch einzelner Begriff im Text) realisiert?
Wie werden URL's mitten im Text dargestellt?
Wie wird zB kursiv realisiert? (oftmals bessere Lesbarkeit).
Die vagen Andeutungen, die bisher gegeben wurden, reichen nicht. Ein Weg, der nicht konkret beschrieben wurde, hat radikal auszuscheiden - meine bescheidene Ansicht. Andernfalls werden wir nie fertig.
Unter den Mitgliedern befinden sich (soweit bekannt) zwei Spezialisten und einer, der gerade handfest am Lernen ist. Es ist unzumutbar, ihnen die gesamte Knobelarbeit zu überlassen. Wenn sie warten, bis wir konkrete Vorbereitungen getroffen haben, ist das vollkommen OK. Das Projekt ist für diese genauso Passion wie für uns. Wir sollten also happy sein, dass sie überhaupt Zeit und Musse finden und ihnen die Hauptarbeit so gut es geht erleichtern. Ist es nicht?
> ? der Autor bin ich doch selber ! wozu an mich eine E-mail?
Gute Frage. Ich denke, dass wir nur eine Maske für alle verwenden: Autor, Lektor, beliebigen weiteren User. Die Kommunikation soll einfach möglich sein. Die e-mail-Adressen sind entweder online abrufbar oder werden in den HTML's gespeichert. An der Tatsache, dass diese Frage und viele andere noch offen stehen, sehe ich, dass nur ganz wenige in der Lage sind, mitzudenken. Der Umgang mit Linux scheint mir durchaus geeignet, freies logisches Denken zu lehren. Entweder, wir haben Geduld oder wir knobeln alles selbst raus (in der Hoffnung, dass auch andere dann damit klarkommen werden).
> Was ist jetzt passiert?
Wie es aussieht, überlagern sich Foren-Eingabe-Maske und die eigene. Ich konnte auch nicht mehr korrigieren. Mein Button überlagerte exakt den Speichern-Button http://www.linuxinfoserver.de/ubb/biggrin.gif .
Auf gutes Weiterknobeln http://www.linuxinfoserver.de/ubb/wink.gif
Bernhard
herzlich willkommen in der nächsten runde des linuxinfoserver-karusell ;D
- zurück aus der novellwelt mit containern und objekten und leaf´s und was weis ich nicht noch alles *schwirr* -
ich denke, wir sollten das formular auf alle fälle so lassen, dass es nicht auf cgi´s angewiesen ist. nicht jeder hat die möglichkeit, immer alles online zu machen. macht ja auch kein sinn. und meine javascript ist ja nur ein bonus, die das schreiben leichter machen soll. - nur mal so als hinweis -
aber natürlich ist die eingabemaske noch nicht fertig! dank manfred hab ich grad gesehen, dass das feld für benutzername&password fehlt. schon peinlich irgendwie http://www.linuxinfoserver.de/ubb/redface.gif
aber über die preview-idee gefällt mir! sollten uns nur überlegen, wie wir das machen, folgende punkte fallen mir dazu mal spontan ein:
<ul> nur ein eingabescript: wir sollten auf alle fälle nur ein eingabescript verwenden, sowohl für die preview als auch für die endgültige eingabe. weil zwecks einfacher handhabbarkeit etc. sollte wohl einleuchten</li> weg der preview durch die scripts: der nächste knobelpunkt. wenn ein beitrag als preview markiert ist, muss er ja gleich nach dem eingabescript das ausgabe-script passieren. man könnte den beitrag natürlich erst in die db schreiben und dann gleich wieder auslesen, aber das erscheint mir wenig professionell. müssten wir uns was überlegen, sollte nicht so das problem sein</li> index-einträge: wohl mit einer der wichtigsten punkte! wenn wir eine preview an unser script-gebälk absetzten sollte dieses natürlich tunlichst keine index-einträge oder ähnliches erzeugen! liesse sich vielleicht mit ner einfachen if-abfrage vor dem setzen der indizies realisieren</li>[/list]
sind alles mal so sachen die mir spontan eingefallen sind, was meint ihr dazu? sollt ja eigentlich alles lösbar sein..
Aber wir sollten mal schaun dass hier was weitergeht! in den letzten Tagen sind ja kaum beiträge zum thema entstanden. ich interpretiere das mal als schöpferische pause, auch meinerseits http://www.linuxinfoserver.de/ubb/wink.gif immer vollgas geht ja ned, aber wir sollten dann mal wieder weiter machen!
ich geh mal davon aus das wir uns drauf geeinigt haben, perl für die eingabe- und php3/4 für die ausgabescripts zu verwenden, richtig? [ php4 ist jetzt raus, soll mächtig schnell geworden sei, hab ich mir von heise-newsticker (http://www.heise.de/newsticker) sagen lassen. vielleicht n diskussionspunt. ganz vielleicht http://www.linuxinfoserver.de/ubb/wink.gif ]
was auch noch abgeht, sind die db´ler die sich nochmal über die struktur der db auslassen. das heisst, halt! da war doch was von Ilja in nem ältren thread *peinlich*. muss ich nochmal nachschauen. trotzdem, das ist auch noch ein wichtiger punkt! bevor wir nicht in etwa wissen, wie die db ausschaut, brauchen wir uns nicht sooo die gedanken um die scripte zu machen. dennoch ist natürlich jeder denkanstoss für die scripten willkommen, ist ja klar http://www.linuxinfoserver.de/ubb/wink.gif http://www.linuxinfoserver.de/ubb/wink.gif
soo jetzt fällt mir erstmal nix mehr ein, kann aber auch dran liegen dass mein bier grad leer ist. ausserdem will ich bernhard den rang für die längsten beiträge ja nicht ablaufen http://www.linuxinfoserver.de/ubb/wink.gif
auf fröhliches weiterknobeln
grüsse blackbird
> ausserdem will ich bernhard den rang für die längsten beiträge ja nicht ablaufen
So ähnlich wie ich jetzt dürfte sich El Killo in der Todeszelle fühlen http://www.linuxinfoserver.de/ubb/biggrin.gif http://www.linuxinfoserver.de/ubb/biggrin.gif .
Hi blackbird
> hab ich grad gesehen, dass das feld für benutzername&password fehlt. schon peinlich irgendwie
Mir nicht. Ich hatte mich bei der Vorlage nur mal auf den Eingabeteil beschrenkt. Für die Passwortabfrage haben wir ein komplettes Beispiel und können es jederzeit dazusetzen http://www.linuxinfoserver.de/ubb/wink.gif . Ich kann es Dir ja mailen.
> bevor wir nicht in etwa wissen, wie die db ausschaut, brauchen wir uns nicht
> sooo die gedanken um die scripte zu machen.
Das Aufarbeiten der Formulareingabe hat mit der Db noch nichts zu tun. Aber stimmt. in Kürze brauchen wir die Struktur.
>index-einträge...
Sobald der Vorbereitungsscript durchlaufen ist, liegt der Eingabetext als HTML vor. Man könnte ihn unter einem StandardNaman speichern (der immer wieder überschrieben wird) und diesen zur Kontrolle ausgeben lassen. Wie wär das?
Uola, ich trainier mal "Aufhören" http://www.linuxinfoserver.de/ubb/biggrin.gif .
Bernhard
hi bernhard! und alle andren die uns hier noch beobachten http://www.linuxinfoserver.de/ubb/wink.gif
>das Aufarbeiten der Formulareingabe hat mit der Db noch nichts zu tun.
naja zum teil schon. einmal muss werden die scripts unsre tags in html-tags übersetzten, aber sie müssen ja auch die db mit inhalten füllen. und damit die wir uns gedanken machen können, welche felder wir mit welchen werten belegen können, müssen wir wissen, welche wir brauchen.
aber natürlich können wir unsren parser unabhängig vom rest erstellen. was da hinten rausfällt, landet ja noch nicht gleich in der db (aber fast)
die name&pw-eingabe kann ich noch schnell hinzufügen, das sollte ja nicht so das problem sein, zwei einzeilige textfenster, eins fürs pw, mit sternchen maskiert. mehr brauchts ja eigentlich nicht.
>sobald der Vorbereitungsscript durchlaufen ist, liegt der Eingabetext als HTML vor. Man könnte ihn unter einem StandardNaman speichern (der immer wieder überschrieben wird) und diesen zur Kontrolle ausgeben lassen. Wie wär das?
naja nicht wirklich. weil das ausgabescript macht ja nochmal n paar formatierungen auf den beitrag. allgemeinen kram halt. hintergrund&tabellenfarben, links, banner etc. und ich denke dass wir das bei der preview auch sehen sollten, damit man erkennt, wie die seite als ganzes wirkt.
naja obwohl *hmm*
könnte man sich nochmal überlegen.
grüsse blackbird
> naja nicht wirklich. weil das ausgabescript macht ja nochmal n paar formatierungen
> auf den beitrag. allgemeinen kram halt. hintergrund&tabellenfarben, links, banner
> etc. und ich denke dass wir das bei der preview auch sehen sollten, damit man
> erkennt, wie die seite als ganzes wirkt.
> naja obwohl *hmm* könnte man sich nochmal überlegen.
Hi blackbird
Ich stell mir das in etwa so vor:
Bei der Aufarbeitung werden zwei HTMLs angelegt. Eine enthält nur die Links. Die zweite enthält den gesamten Text ab Hauptüberschrift. Programm-Optionen sind in (sichtbaren) Tabellen eingearbeitet, Kommandozeilen-Eingaben nebst Erklärung in (unsichtbaren). Die Formatierung bei der Eingabe muss der Autor im Prinzip gar nicht abwarten. Bei der Ausgabe soll nicht mehr formatiert werden müssen. Es genügt, wenn alles zusammengesucht wird. So können die Zeiten sicher erheblich verkürzt werden.
Banner machen eigentlich nur auf den Seiten des Servers voll sinn. Der fleissige Bookmark-Besucher soll nicht durch die Ladezeiten der Banner für jede gefundene Seite "bestraft" werden. Beim gepackten Download nützen die Banner ohnehin nichts. Als ggf vertretbare Alternative könnten Banner auf den ersten Index-Seiten und auf den ersten Themen-Seiten erscheinen. Man muss berüchsichtigen, dass bei flutschenden Such- und Ladezeiten der Besucher auch gern wieder reinschaut.
Würde mich mal interessieren, welch Meinung andere so vertreten. Ist gut möglich, dass ich völlig falsch liege.
Gruss
Bernhard
hi bernhard!
also ich seh das mit den beiträgen und der db noch ein bisschen anders:
ein beitrag kommt an, unser script zerpflückt das nach allen regeln der kunst, tauscht die tags aus usw.. was da dann hinten rauskommt, ist noch keine komplett fertige html-seite. es fehlt noch der kopf, die allgemeinen farbangaben, die hintergrundfarben für die tabellen etc.
alles was fehlt, wird bei der ausgabe eines beitrages erst hinzugefügt. und zwar über das ausgabe-script und eine vorlagendatei, ein template. dadurch können änderungen an der optik relativ schnell und einfach durchgeführt werden. das template ändern und gut ist. was auch nicht zu verachten ist, es wird auch platz in der db gespart! wird sich am anfang zwar wohl noch nicht so bemerkbar machen, aber man muss ja nichts künstlich aufblasen.
und ausserdem: wenn wir komplette html-seiten in die db stellen, wozu dann überhaupt ne db? dann könnten wir ja auch einfach wieder eine file/directory-struktur anlegen, und damit arbeiten. das wäre dann sicher schneller und einfacher zu administrieren..
oder hab ich dich nur wieder falsch verstanden? ich hoffs mal nicht..
achja! dein formular ist angekommen, werd ich demnächst auch mit auf die seiten klatschen!
grüsse blackbird
Hi blackbird
Verschwommen kam ich schon auf Deinen Denkansatz, als ich heute Morgen die Antwort zu Iljas Thread geschrieben habe. Es wäre unlogisch, zB PHP-Anweisungen so zuzufügen, dass sie mit "eingelagert" werden. Jetzt, wo Du's sagst, eine schlanke Db ist eine schnelle Db.
Die Ausgabe-Bearbeitung hat auch noch andere Vorteile. ZB können auf Wunsch die Seiten für CSS vorbereitet werden, und anderes mehr.
Im Zusammenhang hab ich mir auch noch mal über die Banner Gedanken gemach: Nachdem der Benutzer seine Vorauswahl getroffen hat, wird ein bestimmtes "Paket" zusammengestellt, dass den Seiten hizugefügt wird. Alle Teile werden einmal geladen und liegen dann im Speicher zum blitzschnellen Einfügen vor. Ob da Banner dabei sind oder nicht, wird der User gar nicht merken. Im Gegenteil könnte "Sortieren" den Zeitbedarf erhöhen. Unsere "Jury" wusste sich ja bisher immer gekonnt von diesen "Ekelbannern" mit idiotisch langen Ladezeiten zu distanzieren. Und auch diese "Extra-Fresszettel-Banner" wird es bei uns nie geben. Die bringen nur lästiges Durcheinander auf den Screen. Diese Dinger wären ein garantierter Fall für "ohne mich" http://www.linuxinfoserver.de/ubb/biggrin.gif .
War sicher kein Fehler, da mal drüber nachzudenken. Das baut klare Ziele, auf die wir zusteuern können.
Gruss
Bernhard
PS Hast ja gar nichts zum Layout gesagt. War wohl doch ein dezenter Griff ins Klo? http://www.linuxinfoserver.de/ubb/biggrin.gif
Hallo
also das mit der CGI Abhängigkeit hat mich in die Sackgasse geführt darum mein Ausrutscher in der Wortwahl: "sinnlos"
das ganze ist aus der Überlegung entstanden: Eine site der Infosammlung ist meistens nicht vollständig es fehlt hier mal ein beispiel, da ein link...
Ausserdem sind die Daten in der DB doch nicht im HTML format gespeichert (sondern? {daher meine Meinung: Für jedes Teil im Document ein Feld in der DB } ASCII-Text mit kürzeln )
Links und textformate WAREN vorgesehen als botton der, wenn er angeklickt wird sofort die bisherige Eingabe formatiert und ein neues inputfeld liefert eben nur für den link/kusiven text der dann mit [weiter] ohne Zeilenumbruch eingefügt werden würde (ich hoffe das versteht einer)
Aber schluß damit
Hi Bernhard und ...
> Der Autor hat in ein HTML-Eingabefeld längeren HTML-formatierten Text eingetragen. Jedes enthaltene HTML-Tag soll eine im Algorithmus bekannte Script-action auslösen.
Ich versteh nicht so richtig wie die Eingaben aussehen sollen
Niemand oder die wenigsten tippen html code von Hand in die maske ein, ich käme da auf die Idee composer oder webmaker oder bluefish generierter Code per drag & drop einzugeben und schon ist das Chaos perfekt siehe oben! http://www.linuxinfoserver.de/ubb/frown.gif
Die Daten in Deiner Sammlung müssen ja auch irgendwie in die DB - ich hab da ein perl skript angefangen welches ich mal Html2ascii.pl nenn und stolpere über falsche Kommentare-tags "<! kommentar >" in meiner Maske waren komments die über mehrere Zeilen gehen ein Problem
... und Tags wie Titel Form Body Html variablen haben in der Maske nichts verloren und müssen gelöscht werden
Tags für Farbe links texformat müssen in die DB noch dazu an die richtige Stelle
die verbleibenden Tags werden gelöscht weil sie sonst unvorhersehbare folgen bei der ausgabe hätten
... und dann gibts da noch tags die keine sind: less <option> <datei> --- diese dürfen nicht gelöscht werden sondern durch &lt &gt substituiert werden
substituiert man hingegen alle tags die dem skript nicht bekannt sind erscheinen allerhand spitze pfeile beim client
Ich wollte Deine Sites filtern und weiß nicht wie das Filtrat aussehen soll und bin jetzt ganz wirr
#!/usr/bin/perl
$indat="/home/mani/download/infosa/crontab.htm";
@tagrules = (); # array mit den erlaubten und verbotenen tags und deren ersatz
#Programmnamen erkennen
@cmd = split ('/', $0);
$aufruf = $argv0 = @cmd[$#cmd];
# Aufrufparameter checken
if (@ARGV[0]) { # Wenn Parameter da, Auswertung starten
$indat = @ARGV[0];
# den inhalt der Datei in eine Variable einlesen
open(ORIGINAL, "<$indat") | | die "Datei nicht gefunden\n";
while(<ORIGINAL>)
{ $_ =~ s/\r+//; # substituiere ein oder mehr return durch nichts (das ist nur für windos)
$_ =~ s/[\n]/\ /; # substituiere ein newline durch ein space muß \ maskiert werden
$Zeilen = $Zeilen . $_; # alles im skalar speichern
}
close(ORIGINAL);
# Alle Kommentare löschen
$Zeilen =~ s/\< !--.*?--\>//g; #alle richtigen Kommentare löschen
$Zeilen =~ s/\< !.*?\>//g ; #alle falschen kommentare löschen
# tags sollen nicht alle einfach gelöscht werden sondern je nach Art unterschiedlich behandelt werden
# fett kursiv ... tags finden bis zum endetag den text ausschneiden und im array speichern
######## bevor alle tags gelöscht werden müssen ggf.noch die links isoliert werden ######
################################################## #######################################
$Zeilen =~ s/\
/\n/gi; #alle br oder BR tags durch newline ersetzen
$Zeilen =~ s/\
/\n/gi;
$Zeilen =~ s/\<.*?\>//g ; # alle tags löschen!
$Zeilen =~ s/\ä\;/ä/g;
$Zeilen =~ s/\ö\;/ö/g;
$Zeilen =~ s/\ü\;/ü/g;
$Zeilen =~ s/\Ä\;/Ä/g;
$Zeilen =~ s/\Ö\;/Ö/g;
$Zeilen =~ s/\Ü\;/Ü/g;
$Zeilen =~ s/\ß\;/ß/g;
$Zeilen =~ s/\<\;/</g;
$Zeilen =~ s/\>\;/>/g;
$Zeilen =~ s/\&\;/&/g;
$Zeilen =~ s/\"\;/"/g;
$Zeilen =~ s/\ \;/\ /g; #geschützes leerzeichen durch leerzeichen ersetzen
# Zieldatei öffnen
# open (OUTDAT,"> $outdat") | | die "Fehler beim Öffnen von $outdat";
print "\n", $Zeilen, "\n";
} else {
print "usage: $aufruf <htmldatei>\n\n";
}
Das ist der Code eines Querdenkers nicht der eines progammierers
beachte das alle newline beim einlesen durch leerzeichen ersetzt werden so gibt es keine kommentare mehr die über mehrere Zeilen gehen
Ein lösungsweg wäre ein hash dessen index nach dem "formatkürzel" benannt werden könnte - so wären alle infos ( position, format, inhalt) und die Reihenfolge im Array gespeichert
hi Blackbird
>ein beitrag kommt an, unser script zerpflückt das nach allen regeln der kunst, tauscht die tags aus usw..
das seh ich auch so!
so jetzt ist es wieder spät genug (was macht Ihr gegen das "Rote-Augen-syntrom"?
Gruß Manfred-B
hi bernhard!
> PS Hast ja gar nichts zum Layout gesagt. War wohl doch ein dezenter Griff ins Klo?
nönö so ists nicht! hab nur momenten wenig zeit, mich drum zu kümmern *seufz* die farben würd ich halt n bissl dezenter machen, so wies hier ist zb. aber dadrüber brauchen wir uns jetzt noch keine gedanken machen! das kommt, wenn wir am ausgabescript angekommen sind, wir sind da ja flexibel http://www.linuxinfoserver.de/ubb/wink.gif
was du mit den bannern jetzt gemeint hast, hab ich zwar nicht so ganz verstanden, aber egal.. hier sorgen die banner ja auch nicht für lange ladezeiten, es wird ja erst die seite geladen, und dann die bilder http://www.linuxinfoserver.de/ubb/wink.gif je nach browser kann man die info´s also auch schon ohne banner lesen. und so gross sind die banner dann auch wieder nicht, über 10k wird wohl kaum eins rausgehen, die sollen ja schnell beim leser sein!
könnt jetzt noch viele ideen zu papier (in dem fall elektronisches, aber egal) bringen, aber muss wieder weitermachen..
grüsse blackbird
Sorry, blackbird,
ich hatte eine Bemerkung von Dir mal so verstanden, als wär die Action überstanden http://www.linuxinfoserver.de/ubb/biggrin.gif . NULL Problemo. Ich stell das Teilchen mal auf meine HP: http://home.t-online.de/home/Omega-X/home.htm unter Eingabeformular(Muster). Wer will, kann sich's laden und anschaun.
Das war übrigens nicht als Farbmuster für die Info-Seiten gedacht. MAn sollen die ohne Farbanweisung und ohne Hintergrund sein (lesbarkeit). Wer will, kann das über Browser-Einstellung oder CSS regeln. Nur für die Seiten des Servers müssen wir uns was überlegen. Und ich denk mal, Anregung werden wir vor allen erhalten, wenn schon mal ein Beispiel vorgegeben wird (das vielleicht niemandem gefällt http://www.linuxinfoserver.de/ubb/wink.gif ).
Gruss
Bernhard
vBulletin® v3.8.6, Copyright ©2000-2012, Jelsoft Enterprises Ltd.