davidsen: Schöne quelltexte

beim ganzen kombinieren von php und html: wie schafft man es eigentlich, dass die quelltexte bei der ansicht über den browser auch noch schön aussehen?

  1. Grüße,

    beim ganzen kombinieren von php und html: wie schafft man es eigentlich, dass die quelltexte bei der ansicht über den browser auch noch schön aussehen?

    wenn du bei "schön"->"eingerückt" oder zumindest "zeilenweise" meinst-> mit viel aufwand. du kannst höchstens statt echo einen umweg nehmen um imme rinen zeilenumbruch (newline) zu haben, sons tnicht viel AFAIK
    MFG
    bleicher

    --
    __________________________-

    FirefoxMyth
    1. [latex]Mae  govannen![/latex]

      Grüße,

      beim ganzen kombinieren von php und html: wie schafft man es eigentlich, dass die quelltexte bei der ansicht über den browser auch noch schön aussehen?

      wenn du bei "schön"->"eingerückt" oder zumindest "zeilenweise" meinst-> mit viel aufwand. du kannst höchstens statt echo einen umweg nehmen um imme rinen zeilenumbruch (newline) zu haben, sons tnicht viel AFAIK

      Wenn man Bereiche hat, die statisch sind oder größtenteils immer gleich bleiben, kann man den PHP-Bereich verlassen, das HTML  wie bei einer reinen HTML-Seite schreiben (mit Einrückungen und Zeilenumbrüchen) und nur die Bereiche, in denen sich etwas ändert, wieder als PHP-Bereich definieren, dann hat man das schon mal so wie gewünscht.

      Ansonsten mit Zeichenketten in Heredoc-Schreibweise arbeiten, auch hier bleiben Einrückungen und Zeilenumbrüche erhalten.

      Für den Rest tut es bei mir eine kleine Klasse, die intern die Anzahl Einrückungen behält und bei jedem Aufruf diese Anzahl Einrückungen ausgibt, solange der Wert nicht geändert wurde.

      Das sieht bei mir so aus (sehr stark vereinfachte Darstellung):

        
      //Indent::set('   '); # Das hier wären zwei mögliche übliche Aufrufe  
      //Indent::set("\t");  
      Indent::set('XY'); # Zur Verdeutlichung nehme ich aber die Zeichenkette XY als Einrückung:  
        
      Indent::iprint('Ein Text'); # Zähler ist noch 0, weil die change()-Methode noch nicht aufgerufen wurde  
      //Ein Text  <-- Ausgabe  
        
      Indent::change(2);  
      Indent::iprint('Ein Text'); # Zähler ist 0 + 2 = 2, also 2x Einrückung  
      //XYXYEin Text  
        
      Indent::iprint('Ein Text'); # Zähler ist immer noch 2 ....  
      //XYXYEin Text  
        
      Indent::change(-1);  
      Indent::iprint('Ein Text'); # Nun ist der Zähler 2 + (-1) = 1, also 1x Einrückung  
      //XYEin Text  
        
      Indent::change(1);  
      Indent::iprint('Ein Text'); # Zähler wird um 1 erhöht, also 1 + 1 = 2x Einrückung  
      //XYXYEin Text
      

      Kann man als Anregung nehmen oder auch lassen :D

      Cü,

      Kai

      --
      A workaround for an avoidable problem often adds clutter and overhead to the program which
      could have been avoided by not creating the problem in the first place.(Garrett Smith/clj)
      Foren-Stylesheet Site Selfzeug JS-Lookup
      SelfCode: sh:( fo:| ch:? rl:( br:< n4:( ie:{ mo:| va:) js:| de:> zu:) fl:( ss:| ls:?
      1. Grüße,
        ich dachte explizit augerufene methoden hätten kein zugriff auf klasseigenschaften bzw. $this wie speicherst du die einrückungstufe?
        MFG
        bleicher

        --
        __________________________-

        FirefoxMyth
        1. [latex]Mae  govannen![/latex]

          Grüße,
          ich dachte explizit augerufene methoden hätten kein zugriff auf klasseigenschaften bzw. $this wie speicherst du die einrückungstufe?

          ohne $this natürlich :D

          Ich habe zwar extrem wenig Ahnung von OOP und dieser ganzen Klassen-Thematik (und komme irgendwie nie dazu, dies zu ändern), aber kurz zusammengestümpert:

          class A {  
            
             private static $ic = 0;  
            
             public static function A1($a1) {  
               self::$ic = $a1;  
             }  
            
             public static function A2() {  
               echo self::$ic;  
             }  
          }  
            
          A::A2();  #0  
          A::A1(3);  
          A::A2();  #3  
          A::A2();  #3  
          A::A1(7);  
          A::A2();  #7  
          
          

          Cü,

          Kai

          --
          A workaround for an avoidable problem often adds clutter and overhead to the program which
          could have been avoided by not creating the problem in the first place.(Garrett Smith/clj)
          Foren-Stylesheet Site Selfzeug JS-Lookup
          SelfCode: sh:( fo:| ch:? rl:( br:< n4:( ie:{ mo:| va:) js:| de:> zu:) fl:( ss:| ls:?
  2. beim ganzen kombinieren von php und html: wie schafft man es eigentlich, dass die quelltexte bei der ansicht über den browser auch noch schön aussehen?

    Du kannst Strings in PHP auch über mehrere Zeilen angeben

      
    $sql = "  
      SELECT Feld1, Feld2, ..., FeldN  
      FROM tabelle  
    ";  
    
    
      
    echo '  
      <body>  
        <h1>Titel</h1>  
        <div id="deineid">  
          <p>Absatz</p>  
        </div>  
      </body>  
    ';  
    
    

    Nur wird halt diese Möglichkeit so gut wie nie genutzt.

    1. [latex]Mae  govannen![/latex]

      Du kannst Strings in PHP auch über mehrere Zeilen angeben

      [...]

      echo '
        <body>
          <h1>Titel</h1>
          <div id="deineid">
            <p>Absatz</p>
          </div>
        </body>
      ';

        
      ~~~php
      // PHP-Code  
      // PHP-Code  
      // PHP-Code  
      ?>  
         <body>  
           <h1>Titel</h1>  
           <div id="deineid">  
             <p>Absatz</p>  
           </div>  
         </body>  
      <?PHP  
      // PHP-Code  
      // PHP-Code
      

      ist viel einfacher, und man kann -je nach Art der Ausgabe- auch noch diverse Escapes sparen.

      Cü,

      Kai

      --
      A workaround for an avoidable problem often adds clutter and overhead to the program which
      could have been avoided by not creating the problem in the first place.(Garrett Smith/clj)
      Foren-Stylesheet Site Selfzeug JS-Lookup
      SelfCode: sh:( fo:| ch:? rl:( br:< n4:( ie:{ mo:| va:) js:| de:> zu:) fl:( ss:| ls:?
    2. Lieber DiBo33,

      Nur wird halt diese Möglichkeit so gut wie nie genutzt.

      ach ja? Also ich bemühe mich, bei meinen Seiten "schöne" Quelltexte zu erzeugen. Kannst ja mal bei meinem Großprojekt hineinschauen, inwieweit mir das auch gelingt: Peutinger-Gymnasium

      Liebe Grüße,

      Felix Riesterer.

      --
      ie:% br:> fl:| va:) ls:[ fo:) rl:° n4:? de:> ss:| ch:? js:) mo:} zu:)
      1. Hi,

        Nur wird halt diese Möglichkeit so gut wie nie genutzt.

        ach ja? Also ich bemühe mich, bei meinen Seiten "schöne" Quelltexte zu erzeugen. Kannst ja mal bei meinem Großprojekt hineinschauen, inwieweit mir das auch gelingt: Peutinger-Gymnasium

        Welche Vorteile hat ein Programmierer überhaupt davon? Wenn man statische HTML-Seiten schreibt ist es für die eigene Überischt besser, wenn man Zeilen entsprechend einrückt. Aber wenn man dynamische Seiten erzeugt reicht es doch, wenn es im Quellcode (z.B. PHP oder Perl) übersichtlich angeordnet ist. Wie dann der erzeugte Quellcode (optisch) aussieht ist doch eigentlich egal?

        Wenn man den HTML-Output analysieren will kann man auch ein Tool wie Firebug benutzen, das das ganze dann wieder übersichtlich darstellt.

        Seht ihr das anders?

        mfG,
        steckl

        1. Hi!

          Welche Vorteile hat ein Programmierer überhaupt davon?

          Kaum einen, üblicherweise. Wenn man seine Ausgabe analysieren will, ist es vorteilhaft, wenn diese gut lesbar ist. Ansonsten ist der Quelltext normalerwiese für den Browser bestimmt, der sich überhaupt nicht um die Formatierung kümmert. Will man sich selbst allerdings auch mit Hilfe des Quelltextes präsentieren, so tut man gut daran, ihn ordentlich schreiben zu lassen.

          Alles hat seine Vor- und Nachteile. Hat man beispielsweise eine Code-Komponente, die ein fertiges Stück HTML erzeugt - zum Beispiel ein Formulargenerator oder ein Datagrid (Ausgabe von tabellarischen Daten) - so muss man dieser noch generell die aktuelle Einrückungsebene übergeben und Code dazuschreiben, der diese immer in die Ausgabe einfügt. Damit wird der Code der Komponente nicht einfacher. Die Frage ist, ob sich der zusätzliche Code inklusive Wartung und auch der damit verbundene Rechenaufwand rentiert.

          Wenn man statische HTML-Seiten schreibt ist es für die eigene Überischt besser, wenn man Zeilen entsprechend einrückt. Aber wenn man dynamische Seiten erzeugt reicht es doch, wenn es im Quellcode (z.B. PHP oder Perl) übersichtlich angeordnet ist. Wie dann der erzeugte Quellcode (optisch) aussieht ist doch eigentlich egal?

          Die Frage ist, wo hat man den größeren Nachteil. Schreibe ich den Text so, dass er in der Ausgabe ordentlich aussieht, sieht es vielleicht bei mir im Code schrecklich aus, weil die Einrückungsebnen von PHP nicht mit denen des zukünftigen HTML übereinstimmen.

          Allerdings kann man mit dem EVA-Prinzip schon eine Menge Sortierung und Ordnung in seinen Code bringen. Dabei gestaltet man seinen Ablauf so, dass die Verarbeitung nur reine Daten erzeugt und kein HTML direkt ausgibt. Dafür ist dann der Ausgabeteil zuständig. So kann man sich die Probleme mit der Vermischung der verschiedenen Ebenen (PHP und HTML) klein halten.

          if (...) {  
            if (...) {  
              if (...) {  
                if (...) {  
                  echo "  <table>\n";  
                  foreach (...) {  
                    echo "    <tr>  
                <td>foo</td>  
                <td>bar</td>  
              </tr>\n";  
                  }  
                  echo "  </table>\n";  
                }  
              }  
            }  
          }
          

          So sieht das vielleicht in der Ausgabe ordentlich aus, aber hier nicht. Es wird auch nicht besser, mit der Heredoc-Syntax:

          if (...) {  
            if (...) {  
              if (...) {  
                if (...) {  
                  echo "  <table>\n";  
                  foreach (...) {  
                    echo <<<LINE  
              <tr>  
                <td>foo</td>  
                <td>bar</td>  
              </tr>  
          LINE;  
                  }  
                  echo "  </table>\n";  
                }  
              }  
            }  
          }
          

          Wie wär's mit EVA?

          $table = array();  
          if (...) {  
            if (...) {  
              if (...) {  
                if (...) {  
                  foreach (...) {  
                    $table[] = array('foo', 'bar');  
                  }  
                }  
              }  
            }  
          }
          

          ?>
          [...]

            <table>  
              <?php foreach ($table as $row): ?>  
              <tr>  
                <td><?php h($row[0]) ?></td>  
                <td><?php h($row[1]) ?></td>  
              </tr>  
              <?php endforeach; ?>  
            </table>
          

          h() ist in dem Beispiel eine Abkürzung und sieht in Gänze mindestens so aus:

          function h($s) {  
            echo htmlspecialchars($s);  
          }
          

          Wenn man den HTML-Output analysieren will kann man auch ein Tool wie Firebug benutzen, das das ganze dann wieder übersichtlich darstellt.

          Jein. Damit bekommt man ein interpretiertes Ergebnis, und Browser sind bekanntlich fehlertolerant. Mit dieser Anzeige findet man nicht alle Probleme, die ein Validator ankreiden würde.

          Lo!

          1. Welche Vorteile hat ein Programmierer überhaupt davon?

            Kaum einen, üblicherweise.

            Denn häufig ist die Konstruktion von HTML/XHTML/HTML5/XHTML5 so geartet, dass HTML gar niccht mehr im Code augenscheinlich ist.

            Hier eine sub aus einem Perl Modul, das zugleich Webform-Server ist.

            sub __webform {  
            	caller eq __PACKAGE__ or die "pivate method call";  
            	my $self = shift;  
            	my $new = shift || 0;  
            	my $ht = '<form' . attr(action=>'', method=>'post').'>'.NL;  
            	my $gid = 0;  
            	$new and $user = sha1_hex( time() . $self->{config}{formid} );  
            	print STDERR ' 2:', $user;  
            	foreach my $g ( sort keys %{ $self->{layout} } ){  
            		$ht .= '<fieldset id="sfm' . ++$gid . '">' . NL  
            			.	'  <legend>' . htmlchars( $self->{layout}{$g}{title} ) . '</legend>' . NL  
            			. 	'  <ul>' . NL;  
            		my $fid = 0;  
            		foreach my $f ( @{ $self->{layout}{$g}{fields} } ){  
            			$ht .= '    <li id="sfm' . $gid . ++$fid . '">';  
            			if( $self->{fields}{$f}{type} =~ /text|textarea|select/ ){  
            				$ht .= '<label'. attr('for', $f) . '>'  
            					. htmlchars( $self->{fields}{$f}{title} )  
            					. ( $self->{fields}{$f}{required}  
            						? '<sup>*</sup>' : '')  
            					. '</label>';  
            			}  
            			if( $self->{fields}{$f}{type} eq "text" ){  
            				$ht .= '<input'  
            					. attr( type=>'text', id=>$f, name=>$f, value=>$self->{fields}{$f}{value} );  
            				$isht5 and $self->{fields}{$f}{required}  
            					and $ht .= attr( required=>undef );  
            				$ht	.= $EM;  
            			}  
            			elsif( $self->{fields}{$f}{type} eq "textarea" ){  
            				$ht .= '<textarea' . attr( id=> $f, name=>$f, cols=>40, rows=>10);  
            				$isht5 and $self->{fields}{$f}{required}  
            					and $ht .= attr( required=>undef );  
            				$ht .= '>' . htmlchars( $self->{fields}{$f}{value} ) . '</textarea>';  
            			}  
            			elsif( $self->{fields}{$f}{type} eq "select" ){  
            				$ht .= '<select' . attr( id=> $f, name=>$f );  
            				$isht5 and $self->{fields}{$f}{required}  
            					and $ht .= attr( required=>undef );  
            				$ht .= '>'.NL;  
            				foreach my $o ( keys %{ $self->{fields}{$f}{value} } ){  
            					$ht .= '      <option' . attr( value=>$o );  
            					$o eq $self->{fields}{$f}{selected} and  
            						$ht .= attr( selected=>undef );  
            					$ht .= '>'. htmlchars( $self->{fields}{$f}{value}{$o} )  
            						. '</option>'.NL;  
            				}  
            				$ht .= '    </select>';  
            			}  
            			elsif( $self->{fields}{$f}{type} eq "check" ){  
            				$self->{fields}{$f}{title}  
            					and $ht .= '<p class=label>'.htmlchars($self->{fields}{$f}{ title} ).'</p>';  
            				$ht .= NL.'      <ul class=sfmcheck>';  
            				foreach my $o ( keys %{ $self->{fields}{$f}{value} } ){  
            					$ht .= '<li><label>'  
            						. '<input' . attr( type=>'checkbox', name=>$f, value=>$o );  
            					exists $self->{fields}{$f}{checked}{$o} and  
            						$ht .= attr( checked=>undef );  
            					$ht .= '>'. htmlchars( $self->{fields}{$f}{value}{$o} )  
            						. '</label></li>';  
            				}  
            				$ht .= '</ul>'.NL.'    ';  
            			}  
            			elsif( $self->{fields}{$f}{type} eq "submit" ){  
            				$ht .= '<label class="hidden" for="'.$f.'">'.t('submitlabel').'</label><input'  
            					. attr( type=>'submit', id=>$f, value=>$self->{fields}{$f}{title} )  
            					. $EM . NL;  
            				$ht .= '    <input'  
            					. attr( type=>'hidden', name=>'formuser', value=> $user	)  
            					. $EM;  
            			}  
            			$ht .= '</li>'.NL;  
            		}  
            		$ht .= '  </ul>'. NL . '</fieldset>' . NL;  
            	}  
            	$ht .= '</form>'.NL;  
            	if( $new ){  
            		open(F, ">>", "sfm.log") or die( t("err sfm.log"). " $!" );  
            		print F 'user=',time(),'-',$user, NL;  
            		close(F);  
            	}  
            	return $ht;  
            }  
            
            

            Für das Formular wird der Versuch gemacht ihm eine lesbare Formatierung zu geben. Aber Verschwenderischer Whitespace ist nicht einmal angesagt, da damit gewisse CSS Formatierungsmöglichkeiten gestört werden.

            HTML Templates sind hier fruchtlos.

            mfg Beat

            --
            ><o(((°>           ><o(((°>
               <°)))o><                     ><o(((°>o
            Der Valigator leibt diese Fische
          2. Hi,

            Eine sehr ausfuehrliche Antwort.

            Wie wär's mit EVA?

            $table = array();

            if (...) {
              if (...) {
                if (...) {
                  if (...) {
                    foreach (...) {
                      $table[] = array('foo', 'bar');

            vielleicht koennte man auch gleich hier den Aufruf von h() einbauen. Dann kann man die Strings auch in Perl ohne [link:http://forum.de.selfhtml.org/archiv/2007/2/t147092/#m954548@title=Umwege] in einem Here-Doc block ausgeben lassen.

            }
                  }
                }
              }
            }

            
            > ?>  
            > [...]  
            > ~~~html
            
              <table>  
            
            >     <?php foreach ($table as $row): ?>  
            >     <tr>  
            >       <td><?php h($row[0]) ?></td>  
            >       <td><?php h($row[1]) ?></td>  
            >     </tr>  
            >     <?php endforeach; ?>  
            >   </table>
            
            

            Das ist wohl die beste Moeglichkeit Programm- und HTML-Code uebersichtlich zu halten.

            Wenn man den HTML-Output analysieren will kann man auch ein Tool wie Firebug benutzen, das das ganze dann wieder übersichtlich darstellt.

            Jein. Damit bekommt man ein interpretiertes Ergebnis, und Browser sind bekanntlich fehlertolerant. Mit dieser Anzeige findet man nicht alle Probleme, die ein Validator ankreiden würde.

            Daran habe ich nicht gedacht, aber es gibt sicher andere Tools, die den HTML-Quelltext in seiner urspruenglichen Form uebersichtlich darstellen koennen.
            Die Frage ist was schneller ist. Entweder gleich "schoenen" HTML-Code erzeugen, oder ein Tool verwenden, das den Code anschliessend formatiert.

            mfG,
            steckl

            1. Hi!

              Wie wär's mit EVA?
                      foreach (...) {
                        $table[] = array('foo', 'bar');

              vielleicht koennte man auch gleich hier den Aufruf von h() einbauen. Dann kann man die Strings auch in Perl ohne Umwege in einem Here-Doc block ausgeben lassen.

              Dagegen! Das widerspricht einerseits dem EVA-Prinzip, weil h() eine ausgabe- und keine verarbeitungsrelevante Funktion ist. Im obigen Programmteil sollen nur Daten erzeugt werden, die unabhängig vom späteren Ausgabemedium sind.

              <td><?php h($row[0]) ?></td>

              Andererseits muss du dann hier im Ausgabeteil immer zwischen bereits behandelten und noch zu behandelnden Werten unterscheiden. Bei "alles sind Rohdaten" fällt diese fehlerträchtige Überlegung weg, weil eben ausnahmslos alles noch kontextgerecht zu behandeln ist.

              Lo!

          3. Hallo dedlfix,

            h() ist in dem Beispiel eine Abkürzung und sieht in Gänze mindestens so aus:

            function h($s) {

            echo htmlspecialchars($s);
            }

            nutzt Du eine solche Kapselfunktion im Live-Betrieb? Ist der Overhead soweit vernachlässigbar, dass man ihn für rein optische Effekte im Quelltext in Kauf nehmen sollte?  
            Ich finde die Idee gut, da er gerade bei sinnvoller Nutzung von PHP (ist m.E. in sich schon ein Template-System, wenn man Verarbeitung und Ausgabe sauber trennt) die Übersichtlichkeit erhöht. Aber damit schaffe ich ja zu jeder Ausgabe einen zusätzlichen Funktionsaufruf. Lohnt das?  
              
            Gruß, Thoralf
            
            1. Hi!

              h() ist in dem Beispiel eine Abkürzung und sieht in Gänze mindestens so aus:

              function h($s) {

              echo htmlspecialchars($s);
              }

              
              > nutzt Du eine solche Kapselfunktion im Live-Betrieb? Ist der Overhead soweit vernachlässigbar, dass man ihn für rein optische Effekte im Quelltext in Kauf nehmen sollte?  
                
              Ja, schon weil der kurze Name deutlich weniger Platz als das ausgeschriebene "echo htmlspecialchars" einnimmt. Die PHP-Kurzform <?= um das echo zu sparen bringt auch noch nicht viel. In diesem Fall ist mir die Wartbarkeit wichtiger als das bisschen Performance, das das kostet. Allerdings:  
                
              "In echt" ist die noch etwas länger, weil noch [ein wenig mehr Funktionalität](/archiv/2008/9/t177348/#m1171971) drinsteckt.  
                
              
              > Aber damit schaffe ich ja zu jeder Ausgabe einen zusätzlichen Funktionsaufruf. Lohnt das?  
                
              Dazu musst du auch das "was kostet es?" ermitteln. Miss die Unterschiede mit einem Tool wie Apache Benchmark (ab) und setz das Ergebnis in Relation zu den für dein Projekt zu erwartenden Zugriffszahlen. Minimal die Performance zu erhöhen bring es kaum, wenn zu Hochlastzeiten deutlich mehr nachgefragt wird, als eingespart wurde.  
                
                
              Lo!
              
              1. N'Abend,

                "In echt" ist die noch etwas länger, weil noch ein wenig mehr Funktionalität drinsteckt.

                Danke! Enthält einige Anregungen und scheint mir lasttechnisch kein wirklicher Faktor zu sein. Werd mir so etwas wohl auch angewöhnen!

                Gruß, Thoralf

        2. Lieber steckl,

          "schöne" Quelltexte

          Welche Vorteile hat ein Programmierer überhaupt davon?

          in der Entwicklung sehe ich im Quelltext sehr viel schneller, wo etwas nicht so läuft, wie ich das beabsichtigt habe, eben weil er nicht so aussieht, wie er soll. Ohne "schöne Formatierung" tue ich mir da sehr schwer, das sofort zu erkennen. Da reicht mir dann das Syntaxhighlighting in der Quelltextansicht meines FF (manchmal) nicht.

          Aber wenn man dynamische Seiten erzeugt reicht es doch, wenn es im Quellcode (z.B. PHP oder Perl) übersichtlich angeordnet ist. Wie dann der erzeugte Quellcode (optisch) aussieht ist doch eigentlich egal?

          Nicht bei der Fehlersuche! Ich brauche z.B. beim Validieren einen übersichtlichen HTML-Code, wenn ich Fehler finden will.

          Wenn man den HTML-Output analysieren will kann man auch ein Tool wie Firebug benutzen, das das ganze dann wieder übersichtlich darstellt.

          Der Browser macht doch aus meiner Tagsoup ein Dokument und erzeugt das entsprechende DOM. Dass das DOM mit meiner Tagsoup nicht mehr unbedingt viel zu tun hat, solltest Du doch auch bestätigen können, oder?

          Seht ihr das anders?

          Ja.

          Liebe Grüße,

          Felix Riesterer.

          --
          ie:% br:> fl:| va:) ls:[ fo:) rl:° n4:? de:> ss:| ch:? js:) mo:} zu:)
        3. Hallo!

          Wie dann der erzeugte Quellcode (optisch) aussieht ist doch eigentlich egal?

          Eigentlich ja. Ist halt eine Frage der Ästhetik. Diese kann "Perfektionisten" schon überproportional wichtig sein. Auch wenn sich wohl 99% der Benutzer überhaupt nicht für den Quellcode interessieren.

          Seht ihr das anders?

          Ja!

          Viele Grüße
          Thorsten

          --
          ie:( fl:( br:< va:) ls:& fo:) rl:° n4:° ss:) de:> js:| ch:? sh:( mo:| zu:)
      2. Hallo,

        Peutinger-Gymnasium

        Aehm.. Großprojekt ??

        Liebe Grüße,
        Michael

        1. Lieber Michael,

          Peutinger-Gymnasium
          Aehm.. Großprojekt ??

          für mich als interessierter Laie ist das ein Großprojekt. Dazu kommt, dass man nicht alles sieht, was dahinter steckt, denn im Hintergrund laufen ein paar Scripte, die für unsere internen Abläufe wesentlich sind, die man aber als regulärer Besucher der Website nicht sieht.

          Liebe Grüße,

          Felix Riesterer.

          --
          ie:% br:> fl:| va:) ls:[ fo:) rl:° n4:? de:> ss:| ch:? js:) mo:} zu:)
  3. Liebe(r) davidsen,

    benutze reine HTML-Dateien als Vorlagen und befülle bestimmte Bereiche darin mit Deinen geskripteten Inhalten. Damit kannst Du die Einrückungen im HTML-Code zumindest teilweise garantieren.

    In Deinen Scripts müsstest Du Dich schon selbst um Einrückungen bemühen. Wie das geht, haben meine Vorposter bereits angeführt.

    Liebe Grüße,

    Felix Riesterer.

    --
    ie:% br:> fl:| va:) ls:[ fo:) rl:° n4:? de:> ss:| ch:? js:) mo:} zu:)
  4. Das würde ich auch gerne wissen. find ich nicht so einfach!

    1. Liebe Jasmina,

      Das würde ich auch gerne wissen. find ich nicht so einfach!

      ist das wieder so ein Content-Spam-Mist?

      Liebe Grüße,

      Felix Riesterer.

      --
      ie:% br:> fl:| va:) ls:[ fo:) rl:° n4:? de:> ss:| ch:? js:) mo:} zu:)
      1. Hello Felix,

        Das würde ich auch gerne wissen. find ich nicht so einfach!

        ist das wieder so ein Content-Spam-Mist?

        Klär mich bitte mal auf, was meinst Du mit "wieder"?

        Liebe Grüße aus dem schönen Oberharz

        Tom vom Berg

        --
        Nur selber lernen macht schlau
        http://bergpost.annerschbarrich.de
        1. Lieber Tom,

          was meinst Du mit "wieder"?

          ach, zur Zeit posten Leute in meinem GB den üblichen SPAM (ist aber offensichtlich händisch eingetragen worden) und ebenso erlebe ich das in einem von mir mitbetreuten Forum. Daher das "[schon] wieder".

          Liebe Grüße,

          Felix Riesterer.

          --
          ie:% br:> fl:| va:) ls:[ fo:) rl:° n4:? de:> ss:| ch:? js:) mo:} zu:)
          1. Hallo

            was meinst Du mit "wieder"?

            ach, zur Zeit posten Leute in meinem GB den üblichen SPAM (ist aber offensichtlich händisch eingetragen worden) und ebenso erlebe ich das in einem von mir mitbetreuten Forum. Daher das "[schon] wieder".

            Ja, so kann man sagen.

            Tschö, Auge

            --
            Verschiedene Glocken läuteten in der Stadt, und jede von ihnen vertrat eine ganz persönliche Meinung darüber, wann es Mitternacht war.
            Terry Pratchett, "Wachen! Wachen!"
            Veranstaltungsdatenbank Vdb 0.3
      2. Hallo,

        Das würde ich auch gerne wissen. find ich nicht so einfach!
        ist das wieder so ein Content-Spam-Mist?

        Ja, ist es.

        Wen es interessiert: ich würde denic.de empfehlen und dann z.B.:
        http://www.diplom.de/Bachelorarbeit-13094/Guerilla_Marketing.html

        Grüße
        Thomas

  5. beim ganzen kombinieren von php und html: wie schafft man es eigentlich, dass die quelltexte bei der ansicht über den browser auch noch schön aussehen?

    HTML muss nicht "schön" sein. Es muss sich zum Debugging eignen. Zeilenumbrüche sind hier wichtig,

    Die Formatierung der Scriptquelle hat für mich Vorrang.

    Schlüsselstellen im HTML gebe ich Randbündig aus.
    Essentielle Blöcke durch zwei Newlines separiert.
    Ansonsten ein Tab (in den meisten Viewern dann 8 Zeichen).
    In Schleifen bei verschachtelten Listen verwende ich auch mal explizitere Einrückung.

    Wer des öfteren mit display:inline-block arbeitet, ist bezüglich Whitespace zwischen Elementen sowieso eingeschränkt.

    mfg Beat

    --
    ><o(((°>           ><o(((°>
       <°)))o><                     ><o(((°>o
    Der Valigator leibt diese Fische
  6. Hallo davidsen,

    beim ganzen kombinieren von php und html: wie schafft man es eigentlich, dass die quelltexte bei der ansicht über den browser auch noch schön aussehen?

    z.B. indem man php und html komplett trennt - HTML-Template, in php einlesen, ausfüllen

    Dann kannst das html stylen und den php-Code übersichtlich formatieren

    Grüsse, armin

    1. z.B. indem man php und html komplett trennt - HTML-Template, in php einlesen, ausfüllen

      Leider hab ich bisher noch kein schönes Template-System bisher gesehen, und damit mein ich nicht mal unbedingt fertige Bausteine.

      Ich arbeite selbst im Moment an einer Art Template-System weil mir die anderen nicht gefallen, habe ich bisher noch meine Probleme Platzhalter und Schleifen richtig ein zusetzten. So das es a) nicht in regulärem HTML/CSS/JS vorkommen kann und b) im Zweifelsfall valide ist.

      1. So das es a) nicht in regulärem HTML/CSS/JS vorkommen kann und b) im Zweifelsfall valide ist.

        Was sprich gegen HTML-Kommetare?

        Die Template-Engine von TYPO3 verwendet z.B. welche in diesem Schema:

        <!-- ###foo### -->
        Inhalt der durch die Template-Engine ersetzt wird
        <!-- ###foo### -->

        alternativ kann man die Dinger auch noch kommenterien und verschachteln

        <!-- ###foo### ab hier beginnt der subpart "foo" -->
        Inhalt der durch die Template-Engine ersetzt wird, aber auch hier können wiede <!-- ###bar### -->weitere suparts<!-- ###bar --> vorkommen
        <!-- ###foo### ende des subparts -->

        Wenn das Template nun ohne Programmcode ausgeführt wird, stehen im Quelltext zwar kommentare, aber der Code ist nachwievor gültig.

        1. Was sprich gegen HTML-Kommetare?

          Muss ich drüber nachdenken.

          "<!--### xxx ###-->" kann man natürlich per Regex sofort erfassen, es ist valide und kein Mensch schreib solche Kommentare.

          Klingt eigendlich gut.