C,C++,C#,Java,

Gegen Javascript ist doch nichts einzuwenden. Man kann damit ein paar feine Sachen machen, es ist die perfekte Ergänzung zu HTML und kein Sicherheitsrisiko. Wenn wir schon bei Dingen sind, die die Welt nicht braucht, dann ist es JScript und VBScript, die obendrein auch noch ein erhebliches Sicherheitsrisiko darstellen.

...und Intercal.

Helium

Mit HTML gleidert man Texte. Du sagt, was Überschriften sind, normaler Text ist, was Listen sind, ... . Wie das ganze formatiert dargestellt wird regelst du dann mit CSS. Wenn beim Client etwas interaktives ablaufen soll, dann hat das absolut gar ncihts mit der Fromatierung eines Textes zu tun. Deswegen wäre es auch unsinn von HTML entsprechendes zu erwarten.

So nach dem Motto: Ich will hier eine Schraube in das Brett drehen. Ich habe mir jetzt auch schon einen Apfel gekauft, aber der hilft mir irgendwie überhaupt nciht dabei die Schraube reinzudrehen.

Das sind einfach zwei Dinge, die absolut nichts miteinander zu tun haben.

Shade Of Mine

Helium schrieb:

Das sind einfach zwei Dinge, die absolut nichts miteinander zu tun haben.

Zope :p

XML kann man zu allem vergewaltigen...

Helium

Shade Of Mine schrieb:

Helium schrieb:

Das sind einfach zwei Dinge, die absolut nichts miteinander zu tun haben.

Zope :p

Was ist "Zope"?

Eben das ist ja das Problem - daß man für jede Aufgabe bei der Internetprogrammierung eine eigene Sprache braucht; Auszeichnung mit HTML,
Darstellung mit CSS, Interaktivität mit Javascript oder cgi-Perl, oder serverseitig
mit PHP oder wie auch immer.

Wie gesagt: hätte man besser erstmal ein paar Jahre gewartet, bis man absehen
hätte können, welche Sprachelemente im Web gebraucht werden, und hätte dann
statt HTML eine passende Sprache standardisiert, die die wesentlichen Elemente
von HTML,Javascript, cgi-Perl, css und Java enthält, und vor allem im Interesse
der Zukunftssicherheit mit Bibliotheken erweiterbar ist.

Man stelle sich vor, C wäre nur mit Integer-Arithmetik und ohne Elemente der Interaktivität standardisiert worden,
und man bräuchte für jedes float x=y+z; eine zweite Programmiersprache, und
für scanf eine dritte.

Helium

Naja zum generieren von HTML-Code kannst du jede Sprache verwenden mit Text ausgabe. Du bist also nicht an PHP oder Perl gebunden. Das ist doch nicht zwingend ein Nachteil. Genauso kannst du auch für andre Sachen dich zwischen mehreren Sprachen entscheiden.

Ob eine einzige Sprache, die sowhol Auszeichnungssprache, als auch allgemeine Script-Srpache ist, die sowohl Server-, als auch Clientseitig läuft, das wahre ist?
Zum Auszeichnen eignen sich Baumstrukturen. Die wenigsten Programmiersprachen sind jedoch Baumartig.

rüdiger

Daß man für die Auszeichnung von Text auf Webseiten eine Sprache wie HTML braucht,
und für selbst die minimalste Interaktivität (Pulldown-Menüs) schon eine zweite.
zeigt, daß HTML als Wahl voreilig war. Hätte man besser gewartet, bis man bemerkt
hätte, wie wichtig gewisse interaktive Features sind und die wesentlichen Elemente von Javascript in HTML übernommen, bräuchte man heute Sachen wie
Javascript nicht.

So etwas wie JavaScript gehört aber nicht in eine Markup-Sprache. Das ist eine vollkommen andere Kategorie. HTML wurde ja sogar immer stärker mit Zeugs vollgestopft, dass nicht in eine Markup-Sprache gehört. Wie font-Tags oder so etwas. Dafür gibt es halt CSS. Wo ist das Problem, dass man für jedes Problem eine angemessene Lösung findet und nicht mit dem Hammer jedes Problem in die Lösung zwinkt?

rüdiger

Wie gesagt: hätte man besser erstmal ein paar Jahre gewartet, bis man absehen
hätte können, welche Sprachelemente im Web gebraucht werden, und hätte dann
statt HTML eine passende Sprache standardisiert, die die wesentlichen Elemente
von HTML,Javascript, cgi-Perl, css und Java enthält, und vor allem im Interesse
der Zukunftssicherheit mit Bibliotheken erweiterbar ist.

absoluter Blödsinn. Das sind alles verschiedene Sachen, die auch getrennt sein sollten. Wie stellst du dir das mit dem "Warten" vor? Ohne das es bereits das Web gegeben hat, hätte sicher niemand JavaScript erfunden.

Wie gesagt, jedes Problem bekommt seine Lösung und nicht eine Lösung bekommt alle Probleme.

Shade Of Mine

Helium schrieb:

Was ist "Zope"?

Ein Applikationsserver in Python.
Ist ein bisschen wie ASP.NET, nur dass es Python verwendet.

Die Templates haben dann keinen Pythoncode mehr integriert, sondern sind 'HTML' dass etwas komisch aussieht

<!-- wenn variable name existiert -->
<dtml-if name>
  <!-- gib es aus -->
  <b>id:</b><br>
  <dtml-var name>
  <br><br>
</dtml-if>

so werden auch loops und alles in XML dargestellt. man kann auch tags in tags haben:
<a href="<dhtml-var url>">
was die sache echt lustig macht...

also bis auf diese template syntax ist Zope genial.

Shade Of Mine schrieb:

also bis auf diese template syntax ist Zope genial.

Ich find eigentlich gerade diese Template-Syntax genial. Java-Code ist schön anzusehen. HTML-Code ist schön anzusehen. In JSP kann man über Scriptlets Java-Code in HTML einfügen und damit dynamische Ausgaben erzeugen (so ähnlich ist es glaub ich bei PHP auch).

Vorteil: Alles was statisch ist, steht als HTML da und ist gleich erkennbar und gut lesbar.
Nachteil: Scriptlets in HTML Code sind nicht schön anzusehen.
Lösung: Custom-Tags

<html>
    <head>...</head>

    <body>
        <%-- Liest irgendwas aus ner Datenbank und zeigt Bestände an --%>
        <p>Hier sehen Sie, wie viel wir noch auf Lager haben.</p>
        [b]<mycustomtags:storagetable/>[/b]
    </body>
</html>

Und sowas gibts dann auch für if und andere Kontrollstrukturen. Markup und Programmcode zu mischen ist wirklich hässlich, ich finde sowas also gut.

absoluter Blödsinn. Das sind alles verschiedene Sachen, die auch getrennt sein sollten<<

Nana. Das zeigt nur, wie sehr Du im eingefahreren Denkschema verharrst.

Genauso wie man die Universalsprache C in weiser Voraussicht so geschaffen hat,
daß sie universell für fast alle Aufgaben geeignet oder dafür erweiterbar ist,
und mit dem Standardisieren gewartet hat, bis sich die verlangte Anwedungsbreite
abschätzen liess, hätte man mit HTML und co. warten sollen, vielleicht bis
2000 oder 2005; dann hätte man sehen können, daß HTML nur einen kleinen Teil der
für Web-Programmierung nötigen Aufgaben erfüllt und eine umfangreichere,
erweiterbare und vor allem für Client und Server benutzbare Sprache schaffen können, die das Chaos von HTML-cgi-Java-Javascript-Perl/Python/Ruby-PHP
verhindern hätte können.

Aber bei C standen eben weniger wirtschaftliche Interessen im Vordergrund als
im Internet-Hype in den 90ern. Deshalb haben wir heute C seit 35 Jahren
im Wesentlichen unverändert
und immer noch aktuell, wogegen die Web-Standards immer wieder ergänzt und
erneuert werden müssen. Das K&R-Buch zu C ist heute noch Standard-Lektüre,
dagegen ist mein "HTML 3.3"-Buch von vor 7 Jahren schon beim Altpapier.

Wenn du auf diese Trennung keinen Wert legst, hast du das Prinzip von Markup-Sprachen nicht verstanden. Lies die Posts von Helium immer wieder durch, bis du es einsiehst.

Und HTML mit C zu vergleichen ist natürlich Blödsinn. Auch ist C keine "Universalsprache", sondern (um es mal zu übertreiben) nicht mehr als ein dünner Wrapper um Assembler. C kann gar nichts, wie soll es denn eine Universalsprache sein? Es unterstützt weder objektorientierte Programmierung, noch generische, noch ...

Wenn du auf diese Trennung keinen Wert legst, hast du das Prinzip von Markup-Sprachen nicht verstanden<<

Markup-Sparchen sind eben viel zu dünn für ein derart heterogenes Anforderungsprofil, wie es der grosse Bereich Web-basioerte Anwendungen
darstellt.

Sieh's mal so: Mit einer ausgereiften Sprache wie C kann man von "Hello world"
bis zum Großrechner-Betriebssystem alles mit einer Sprache programmieren.
aber um ein Window im Browser aufpoppen zu lassen, braucht man 2 Sprachen, und
für Client-Server dann noch 2 andere plus Perl - da kann was einfach nicht
durchdacht sein.

Außerdem ist das Markup-Konzept von HTML sowieso verwässert:
Eine Markup-Sprache im reinen Sinne dürfte nicht Sachen enthalten wie
"<frameset rows=140px ..."
wohl aber
<frameset rows=30%..."
denn mit pixel ist man an eine Darstellungsart gebunden, was z.B. einen
Plotter ausschliesst - also eine Vermischung von Darstellung und Inhalt bei
HTML.

Fazit: Es bleibt dabei. Die Web-Sprachenvielfalt ist "kein Feature, sondern
ein Bug".

ChockoCookie

zwiebelsuppe schrieb:

Außerdem ist das Markup-Konzept von HTML sowieso verwässert:

Das mag sein, allerdings kommt man von solchen sachen mit XHTML eher wieder ab. Und ein riesiges monolithisches gebilde für alles was mit web zu tun hat, halte ich für unangebracht.
HTML ist ja nicht nur dazu gedacht Webseiten darzustellen, sondern dazu reinen, für die Maschine unlesbaren Text mit menschlicher Semantik zu versehen. Und gerade das sich HTML weitestgehend auf diese Aufgabe beschränkt, macht es so flexibel. zB ein Textmodebrowser wie Lynx könnte gar nicht den kompletten Standard implementieren, müsste er auch Dinge wie Stylesheets uä unterstützen.
Oder was ist mit Offlinedokumentation a la man Seiten? Wie willst du denn für einen reinen Offline Client Server-Preprocessing realisieren? Wie gesagt, HTML ist nicht nur für Web Designer.

Shade Of Mine

zwiebelsuppe schrieb:

Markup-Sparchen sind eben viel zu dünn für ein derart heterogenes Anforderungsprofil, wie es der grosse Bereich Web-basioerte Anwendungen
darstellt.

Richtiges Tool für die Aufgabe.
Die Trennung von Content Struklturierung, Content Design und Content Generierung ist vital.

Sieh's mal so: Mit einer ausgereiften Sprache wie C kann man von "Hello world"
bis zum Großrechner-Betriebssystem alles mit einer Sprache programmieren.

Es macht aber idR keinen Sinn für alles C zu nehmen.

Optimizer schrieb:

Ich find eigentlich gerade diese Template-Syntax genial. Java-Code ist schön anzusehen. HTML-Code ist schön anzusehen. In JSP kann man über Scriptlets Java-Code in HTML einfügen und damit dynamische Ausgaben erzeugen (so ähnlich ist es glaub ich bei PHP auch).

Klar, nix gegen eine Templatesprache (wobei ich da lieber gleich PHP embedde)

Vorteil: Alles was statisch ist, steht als HTML da und ist gleich erkennbar und gut lesbar.

Wirklich? Ist ein
<dhtml-if foo>
X
</dhtml-if>
wirklich so logisch?

problem ist: XML ist keine Programmiersprache. Deshalb finde ich das Konzept XML dazu umzumodeln irgendwie falsch.

Denn spätesten bei einer verschachtelten Schleife steigt man doch aus, weil Content und Logik gleich aussieht - es gibt keine Trennung (nicht mal eine optische).

Wenn man naemlich jetzt den Schritt geht, und nur XML produziert und kein HTML, hat man ein Problem: was macht der Tag? Ok, man kann sagen, alles was mit <dhtml> beginnt ist ein Zope Tag, aber das kann es doch nicht sein, oder?

Und sowas gibts dann auch für if und andere Kontrollstrukturen. Markup und Programmcode zu mischen ist wirklich hässlich, ich finde sowas also gut.

Ja, aber ich finde es schöner, wenn eine Schleife anders aussieht als eine Textausgabe

<dhtml-if foo>
  <p><dtml-var foo></p>
</dhtml-if>

<!-- versus -->

{if $foo}
  <p>{$foo}</p>
{/if}

ich finde variante 2 schöner.
weil ich klar erkennen kann was textausgabe ist und was eine kontrollstruktur.

vorallem wenn es nicht um HTML sondern XML geht, wo man die Tags nicht alle auswendig kennt.

zwiebelsuppe schrieb:

Genauso wie man die Universalsprache C in weiser Voraussicht so geschaffen hat, daß sie universell für fast alle Aufgaben geeignet oder dafür erweiterbar ist,und mit dem Standardisieren gewartet hat, bis sich die verlangte Anwedungsbreite abschätzen liess,

Auch Schwachsinn! C wurde von D. Ritchie und K. Thompson für UNIX entwicklet.

Dieser Thread erinnert mich an einen ähnlichen in diesem Forum

Shade Of Mine schrieb:

<dhtml-if foo>
 <dtml-var foo>
</dhtml-if>



{if $foo}
 {$foo}
{/if}
weil ich klar erkennen kann was textausgabe ist und was eine kontrollstruktur.

vorallem wenn es nicht um HTML sondern XML geht, wo man die Tags nicht alle auswendig kennt.

Ich finde dein konkretes Beispiel als Tag auch hässlich. Liegt wahrscheinlich irgendwie an der Bennenung, oder am Highlighting, keine Ahnung. Das ist aber IMHO ein konkretes Problem und lässt sich so nicht verallgemeinern.

Ich kann prinzipiell nicht ganz verstehen, was du z.B. gegen ein

<c:if value="...">
        <p>Nene!</p>
    </c:if>

hast. Wenn Das ist jetzt nur ein ganz kleiner Brocken Code. Wenn du aber ne größere Seite hast, die mit Scriptlets durchsetzt ist, hast du einfach nur noch nen Riesensalat und das ist bei PHP auch nicht besser. Und so hast du für alles schön Tags.

Außerdem siehst du es IMHO auf einer zu niedrigen Ebene. Man wird normalerweise viel größere Teile in ein Custom-Tag auslagern. z.B. ein Tag

<div>
    ...
    <mycustomtags:listAllEntries showHidden="true"/>
    ...
</div>

Wo dann das Tag das if( keine Einträge vorhanden ) selber vornimmt und nur ausgibt "Es existieren zur Zeit keine Einträge". Sich eigene Tags zu schreiben finde ich zukunftsträchtig.
Na wie auch immer, Markup-Code mit Programmcode zu mischen finde ich in jedem Fall verdammt hässlich.

interpreter

Marc++us schrieb:

fixer schrieb:

Wie fixt man das Problem?

Datumsroutinen verwenden, die auf 64 Bit basieren.

Dadurch verschiebt man das Problem ja auch nur nach hinten... *scnr

Auch Schwachsinn! C wurde von D. Ritchie und K. Thompson
für UNIX entwicklet. <<

Das ist ja was *ganz* neues!