Code etwas schöner schreiben

[XxNeleXx]

Moin,

ist es möglich diesen Code etwas schöner und kürzer zu schreiben? Ich finde es wird immer unübersichtlicher in meiner Datei:

  
        <?php  
			if (!$_REQUEST['modul'] == 'ueberMich')  
	  {  
?>  
dcdd  
<?php  
}  
	  else  
	  {  
     ?>  
dcdd  
<?php  
  
	  }  

und was ist, wenn ich noch ein zweites Modul einbinde? wird von Zeile zu Zeile schlimmer. Gibts eine alternative?

[Gunnar Bittersmann]

@@XxNeleXx:

nuqneH

Gibts eine alternative?

Ja.

Qapla'

[Der Martin]

Hallo,

Gibts eine alternative?
Ja.

und ich frage mich immer wieder: Was finden manche Menschen an dieser alternativen Syntax besser?

Denn eigentlich sehe ich keinen wirklichen Unterschied zur klassischen Syntax. Die öffnende Klammer mutiert zu einem Doppelpunkt, die schließende zu einem "endif", "endfor", endwhile" oder etwas entsprechendem. Okay, und wo ist nun der Vorteil? Nach meinem Dafürhalten ist es einfach nur anders - nicht besser, aber auch nicht schlechter als man es sonst gewöhnt ist.

Ciao,
 Martin

[tami]

hi,

und ich frage mich immer wieder: Was finden manche Menschen an dieser alternativen Syntax besser?

Denn eigentlich sehe ich keinen wirklichen Unterschied zur klassischen Syntax. Die öffnende Klammer mutiert zu einem Doppelpunkt, die schließende zu einem "endif", "endfor", endwhile" oder etwas entsprechendem. Okay, und wo ist nun der Vorteil? Nach meinem Dafürhalten ist es einfach nur anders - nicht besser, aber auch nicht schlechter als man es sonst gewöhnt ist.

http://forum.de.selfhtml.org/archiv/2010/11/t201645/

Darin Sven: "Der Grund ist, dass die unvermeidliche Mischung von Kontrollstrukturen und Schleifen, die zwangsläufig in PHP stattfinden wird, mit direktem HTML-Output (niemand mag endloses Echo), auf diese Weise zu einer übersichtlicheren Struktur führt, als wenn man unvermittelt, vor allem bei Verschachtelungen, einfach nur auf eine schließende Klammer trifft, bei eben nicht auf den ersten Blick klar ist, ob die nun zu dem angefangenen IF, FOREACH oder SWITCH gehört."

http://framework.zend.com/manual/1.12/de/zend.view.introduction.html

"In unseren Beispielen verwenden wir PHP Long Tags: <?php. Wir empfehlen auch die » alternative Syntax für Kontrollstrukturen. Diese sind übliche Abkürzungen die verwendet werden, wenn View-Skripte geschrieben werden, da sie Konstrukte verständlicher machen, die Anweisungen auf einer einzelnen Zeile belassen und die Notwendigkeit eleminieren nach Klammern im HTML zu suchen."

mfg

tami

[Der Martin]

Hallo,

Nach meinem Dafürhalten ist es einfach nur anders - nicht besser, aber auch nicht schlechter als man es sonst gewöhnt ist.
http://forum.de.selfhtml.org/archiv/2010/11/t201645/
Darin Sven: "Der Grund ist, dass die unvermeidliche Mischung von Kontrollstrukturen und Schleifen, die zwangsläufig in PHP stattfinden wird, mit direktem HTML-Output (niemand mag endloses Echo), auf diese Weise zu einer übersichtlicheren Struktur führt, als wenn man unvermittelt, vor allem bei Verschachtelungen, einfach nur auf eine schließende Klammer trifft, bei eben nicht auf den ersten Blick klar ist, ob die nun zu dem angefangenen IF, FOREACH oder SWITCH gehört."

das ist aber nur ein Votum gegen die Verwendung von langen echo-Wüsten. Der Beitrag geht in keiner Weise auf die Verwendung der klassischen vs. alternativen Syntax für Kontrollstrukturen ein, außer mit der Anmerkung, dass der Coding Style des ZEND Framework das empfiehlt. Warum? Das wissen wir immer noch nicht. Eine schließende Klammer gehört immer zur letzten öffnenden Klammer; die Verwendung *unterschiedlicher* Keywords stattdessen macht es IMO nur komplizierter. Üblicherweise unterstützt man die Übersichtlichkeit von Klammern bzw. Klammer-Ebenen noch durch entsprechende Einrückung.

http://framework.zend.com/manual/1.12/de/zend.view.introduction.html

"In unseren Beispielen verwenden wir PHP Long Tags: <?php. Wir empfehlen auch die » alternative Syntax für Kontrollstrukturen. Diese sind übliche Abkürzungen die verwendet werden, wenn View-Skripte geschrieben werden, da sie Konstrukte verständlicher machen, die Anweisungen auf einer einzelnen Zeile belassen und die Notwendigkeit eleminieren nach Klammern im HTML zu suchen."

Für mich, der ich mit C groß geworden bin, ist diese alternative Syntax eher verwirrend, kryptisch, schwerer zu erfassen und zu lesen.

So long,
 Martin

[Mike]

Hallo,

Für mich, der ich mit C groß geworden bin, ist diese alternative Syntax eher verwirrend, kryptisch, schwerer zu erfassen und zu lesen.

kann zwar leider kein C aber ich sehe es genauso. Ich habe mir ein Zeitlang diese Kurzschreibweisen angewöhnt und dann wieder abgewöhnt, als ich merkte wie mühselig es war später meine eigenen Scripte zu analysieren. Klammern sind intuitiver!

Gruss
Mike

[tami]

hi,

das ist aber nur ein Votum gegen die Verwendung von langen echo-Wüsten. Der Beitrag geht in keiner Weise auf die Verwendung der klassischen vs. alternativen Syntax für Kontrollstrukturen ein, außer mit der Anmerkung, dass der Coding Style des ZEND Framework das empfiehlt. Warum? Das wissen wir immer noch nicht. Eine schließende Klammer gehört immer zur letzten öffnenden Klammer;

Nach hundert Zeiten HTML code?

" ...vor allem bei Verschachtelungen, einfach nur auf eine schließende Klammer trifft, bei eben nicht auf den ersten Blick klar ist, ob die nun zu dem angefangenen IF, FOREACH oder SWITCH gehört."

???

mfg

tami

[Der Martin]

Hallo,

Eine schließende Klammer gehört immer zur letzten öffnenden Klammer;
Nach hundert Zeiten HTML code?

das wäre IMO ein unästhetisches Code-Design. Aber unabhängig davon treten vor allem for- und if-Statements gern mehrfach verschachtelt auf, ...

" ...vor allem bei Verschachtelungen, einfach nur auf eine schließende Klammer trifft, bei eben nicht auf den ersten Blick klar ist, ob die nun zu dem angefangenen IF, FOREACH oder SWITCH gehört."

... so dass ich auch bei einem endif nicht automatisch sehe, zu *welchem* einleitenden if das eigentlich gehören will. Also muss ich doch wieder rückwärts im Code laufen und zuordnen, oder mich auf die Einrückungstiefe als Orientierung stützen. Daher meine Aussage, ich erkenne den Vorteil nicht.

Ciao,

[Gunnar Bittersmann]

@@Der Martin:

nuqneH

das wäre IMO ein unästhetisches Code-Design. Aber unabhängig davon treten vor allem for- und if-Statements gern mehrfach verschachtelt auf, ...

In der Business-Logik,ja.

Alternative finden aber vorzugsweise bei der _Ausgabe_ Verwendung, dort, wo das HTML generiert wird. In den Views bei MVC.

Wenn man dort vielfache Verschachtelungen hat, macht man was falsch.

Qapla'

[hotti]

Hi,

das ist aber nur ein Votum gegen die Verwendung von langen echo-Wüsten. Der Beitrag geht in keiner Weise auf die Verwendung der klassischen vs. alternativen Syntax für Kontrollstrukturen ein, außer mit der Anmerkung, dass der Coding Style des ZEND Framework das empfiehlt. Warum? Das wissen wir immer noch nicht. Eine schließende Klammer gehört immer zur letzten öffnenden Klammer; die Verwendung *unterschiedlicher* Keywords stattdessen macht es IMO nur komplizierter.

Genau! Ich kannte mal einen, der fand es cool, seitenlange Strings zwischen zwei Tilden zu setzen anstatt Klammern zu verwenden, wo jeder mittelmäßige Editor per Shortcut die Gegenstücke findet.

SCNR;

[Gunnar Bittersmann]

@@Der Martin:

nuqneH

Warum? Das wissen wir immer noch nicht.

{ … } ist in PHP ein Block. Bei { ?> foo <?php } hat man aber keinen PHP-Block mehr.

Da finde ich { …:> foo <?php end… dann doch sauberer als einen PHP-Block durch HTML zu unterbrechen.

Üblicherweise unterstützt man die Übersichtlichkeit von Klammern bzw. Klammer-Ebenen noch durch entsprechende Einrückung.

Alternative finden aber vorzugsweise bei der _Ausgabe_ Verwendung, dort, wo das HTML generiert wird. Wo PHP-Code und HTML-Code gemischt vorkommen. Dabei eine saubere Einrückung hinzubekommen, ist sowieso eine Wissenschaft für sich.

Für mich, der ich mit C groß geworden bin, ist diese alternative Syntax eher verwirrend, kryptisch, schwerer zu erfassen und zu lesen.

Die Views ist auch eher das Arbeitsfeld derer, die mit HTML groß geworden sind. Und in HTML gibt es auch nicht Klammern, sondern paarweise Tags, wo im schließenden der Bezeichner aus dem öffnenden wiederholt wird.

Qapla'

[Gunnar Bittersmann]

@@Gunnar Bittersmann:

nuqneH

Da finde ich { …:> foo <?php end… dann doch sauberer als einen PHP-Block durch HTML zu unterbrechen.

Die { muss da natürlich weg. Wo ist die Editierfunktion?

Qapla'

[Der Martin]

Hallo,

{ … } ist in PHP ein Block. Bei { ?> foo <?php } hat man aber keinen PHP-Block mehr.

wirklich nicht? Es ist IMO nur eine andere Schreibweise für den Block.

Die Views ist auch eher das Arbeitsfeld derer, die mit HTML groß geworden sind. Und in HTML gibt es auch nicht Klammern, sondern paarweise Tags, wo im schließenden der Bezeichner aus dem öffnenden wiederholt wird.

Stimmt. Und das ist bei entsprechend konfusem Markup, wo plötzlich mehrere schließende div- oder span-Tags aufeinander folgen, auch nicht wirklich übersichtlich. Wie schnell ordnet man mal Start- und Endtag falsch zu, vor allem wenn der Autor sich beim Einrücken vertan hat (oder ganz darauf verzichtet).

Ciao,
 Martin

[Gunnar Bittersmann]

@@Der Martin:

nuqneH

{ … } ist in PHP ein Block. Bei { ?> foo <?php } hat man aber keinen PHP-Block mehr.

wirklich nicht?

Wirklich nicht. Wie kann Code, der durch ?> abbrochen, durch HTML-Code unterbrochen, dann durch <?php wieder aufgenommen wird, denn _ein_ PHP-Block sein?

Qapla'

[Der Martin]

Hi,

{ … } ist in PHP ein Block. Bei { ?> foo <?php } hat man aber keinen PHP-Block mehr.
wirklich nicht?
Wirklich nicht. Wie kann Code, der durch ?> abbrochen, durch HTML-Code unterbrochen, dann durch <?php wieder aufgenommen wird, denn _ein_ PHP-Block sein?

weil PHP nicht so arbeitet. Wenn du den PHP-Modus mit ?>some html<?php unterbrichst, ist das für den PHP-Parser gleichbedeutend mit einer langen echo-Anweisung oder einer Heredoc-Notation (abgesehen von der Variablen-Ersetzung). Das sind nur unterschiedliche Arten, um letztendlich doch das Gleiche zu notieren.

Der PHP-Parser arbeitet nämlich nicht blockweise (im Sinn von <?php ... ?>), sondern parst und analysiert das gesamte Dokument als Einheit.

Ein in einem PHP-Abschnitt begonnener und in einem späteren PHP-Abschnitt beendeter Block bleibt daher aus der Sicht von PHP ein Block. Das dazwischen notierte Markup ist als direkt ausgegebener String Teil dieses Blocks.

Ciao,
 Martin

[Gunnar Bittersmann]

@@Der Martin:

nuqneH

aus der Sicht von PHP

Um die Sicht geht’s doch aber nicht, sondern um die Sicht menschlicher Codeleser. Die sehen Beginn PHP-Block – Ende PHP-Code – HTML-Code – Beginn PHP-Code – Ende PHP-Block. Das sieht schon seltsam aus.

Ein einfaches PHP-Code – HTML-Code – PHP-Code mit alternativer Kontrollstruktur finde ich sauberer.

Qapla'

[Der Martin]

Hallo,

aus der Sicht von PHP
Um die Sicht geht’s doch aber nicht, sondern um die Sicht menschlicher Codeleser. Die sehen Beginn PHP-Block – Ende PHP-Code – HTML-Code – Beginn PHP-Code – Ende PHP-Block. Das sieht schon seltsam aus.

ach, so meinst du das mit dem Block. Okay, da habe ich kein Problem, aber ich kann deine Sichtweise nachvollziehen, jetzt, nachdem ich verstanden habe, was du meintest. Ich hatte das eher von der technischen Seite betrachtet.

Ein einfaches PHP-Code – HTML-Code – PHP-Code mit alternativer Kontrollstruktur finde ich sauberer.

Geschmackssache[*]. ;-)

Ciao,
 Martin

[*] Geschmackssache, sagte der Affe, und biss in die Seife.
    Geschmackssache, sagte der Igel, und stieg von der Klobürste.

[molily]

Hallo,

if (!$_REQUEST['modul'] == 'ueberMich')

Das sieht so aus, als würdest du den Inhalt verschiedener Seiten in einem PHP-Script unterbringen…?

Gibts eine alternative?

Lagere den HTML-Code in unterschiedliche Dateien aus, die du wahlweise einbindest.

Mathias

[Der Martin]

Hallo,

if (!$_REQUEST['modul'] == 'ueberMich')

das superglobale Array $_REQUEST ist eine Zusammenfassung der Werte aus $_GET, $_POST und $_COOKIE. Normalerweise empfiehlt man, die Daten gezielt aus *einer* dieser Quellen zu holen. Die Request-Methoden GET oder POST wählt man üblicherweise bewusst aus, und wenn ein Wert aus einem Cookie kommen soll, weiß man das in der Regel auch.

Es gibt also eigentlich keinen Grund, sich aus dem Wühltisch zu bedienen. Das ist nur eine mögliche Fehlerquelle für den Fall, dass Daten auf einem Weg übergeben werden, den man nicht erwartet.

So long,
 Martin

[tami]

hi,

<?php if($view->show()):?>  

~~~`<h1>Hallo Du <[code lang=php]?php echo $view->name?>`{:.language-html}<h1>  
[/code]~~~php
<?php else:?>  

~~~~~~html
<p>melde dich erstmal an</p>  

~~~~~~php
<?php endif?>  

den link dazu hat dir gunnar ja geschickt.

mfg

tami

[hotti]

Moin,

und was ist, wenn ich noch ein zweites Modul einbinde? wird von Zeile zu Zeile schlimmer. Gibts eine alternative?

PHP als Templatesprache:
Reduziere Kontrollstruktutren im Template auf ein Minimum. Tausche das Template aus, wenn die Kontrollstrukturen komplizierter werden. Greife im Template nicht auf globale Variablen. Greife im Template nur auf Variablen, die DU dafür bestimmt hast. Eine Kontrolle über HTTP-Request-Parameter hat im Template nichts zu suchen.

PHP als Progammiersprache:
Hier liegt die Programmlogik. Hier liegen die Kontrollstrukturen über Requestparameter. hier daf es auch komplizierte Kontrollstrukturen geben.

Trenne Businesslogik vom Templateengineering.

Schönen Sonntag,
Horst

[Tabellenkalk]

Hallo

ist es möglich diesen Code etwas schöner und kürzer zu schreiben? Ich finde es wird immer unübersichtlicher in meiner Datei:

<?php if (!$_REQUEST['modul'] == 'ueberMich') { ?>
dcdd
<?php } else { ?>
dcdd
<?php }

>   
  
Wenn du in beiden Fällen "dcdd" ausgeben möchtest, kannst du if-else-Konstruktion auch wechlassen...  
  
Gruß  
Kalk