nicht angemeldet
Meine Meinung dazu ist, dass nicht die eigentliche Problemanalyse und die ersten Lösungsansätze so komplex sind, sondern dass man sich sehr leicht in der "Request-Response"-Auflösung und der Eigenschaft von HTTP, der Zustandslosigkeit, verzettelt.
Mag sein dass das vorgestellte System da Abhilfe schafft. Aber dann ist die Seite noch schlechter gemacht als ich eh schon dachte. Es dauert alles ewig und nirgends steht um was es eigentlich geht. Bzw. nirgends wo man es innerhalb akzeptabler Suchzeit findet.
Sooo schwer find ich das Browserkopzept übrigens auch nicht (Request-Response). Eigentlich sollte man das doch immer im Hinterkopf haben, schließlich hat man ja mit genau diesem Prinzip zu tun und die eigentliche Kunst der meisten Webprogramme liegt ja nicht an Problemen dieses Prinzips.
Mir hat die Seite jedenfalls nicht gesagt was sie genau kann. Andere Schreibweisen zur Verschleierung von HTML-Tags sind halt drin, soweit ich das seh. Aber ob ich das brauche? Dann kapier ich nicht mehr wie mein HTML-Code zustandegekommen ist, wenn im Browser was nicht gut aussieht.
OOP ohne voerhergehende Analyse und Plangestaltung ist mMn überhaupt nicht möglich. Klassische Top-Down-Programmierung mittels eines Interpretersystems (wie z.B. PHP) kann hingegen auch noch mittels Trial & Error geschehen, auch wenn das nicht klug ist.
Mit OOP kann man das doch auch noch. Ich programmiere sehr viel OOP und das wird auch oft was ohne dass ich vorher viel plane.
Es ist halt überall eine Klasse drum herum. Aber mit lauter statischen Methoden oder von mir aus nur einer einzigen Instanz einer Klasse hat man fast die selben Voraussetzungen wie top-down. Können sollte mans natürlich, aber auch mit OOP kann man "simpel" programmieren.