Direkt zum Hauptbereich

Editing and Persistence



In this post, I want to present a generalization of the ideas, which are behind HTML, CSS and JavaScript. We will end up with a broad understanding of what is meant by editing und persistence in the context of an object model.

Most of you know HTML, the HyperText Markup Language, which is at the heart of web technology. For those who don't know it: The content of a web page is described with HTML. HTML structures the content of a web page hierarchically. Furthermore, the content is annotated by so-called tags. A tag indicates the logical purpose of a piece of content. Is some content supposed to be a header, a paragraph, a highlighted word etc.? For further info see e.g. Wikipedia on HTML or any other of the hundreds of resource about HTML.

HTML is flanked by two other guys. One guy is called CSS, the other JavaScript. When you look at a HTML page in a browser, the graphics engine (the rendering engine) takes the HTML stuff and calculates a visual presentation out of it. There are some predefined rules, which let a header, for instance, appear in big, fat letters. With CSS (Cascading Style Sheets) you can define your own style information. You can do quite some fancy things with CSS in order to change the default behavior of the rendering engine. Have a look at CSS Zen Garden -- the same content is presented in astonishingly different ways, just the CSS is exchanged.

Before we come to the other guy, JavaScript, you have to know that your browser internally converts HTML into an alternative representation, an object model called DOM (Document Object Model). It's a data structure, which represents HTML in form of a tree. The fun part is that the tree has a defined interface (we call it an API, Application Programmer Interface) to inspect the tree, navigate through it, add or delete nodes or node attributes. You couldn't do this in HTML. So once HTML is consumed by the browser, HTML "disappears" and continues to live in the browser in a different form: as a DOM. The object model can be traversed at any time and the HTML form can be reconstructed. An HTML page can be transformed into DOM and vice versa.

JavaScript is a programming language all browsers understand. With JavaScript you can manipulate HTML and CSS via DOM. CSS is also accessible via DOM. This gives you quite some power to dynamically change content and its appearance. It's the miracle behind some fancy visual effects, web designers create on some web pages with JavaScript.

In addition, JavaScript can overwrite all standard reactions on user initiated events. When you click on a link with the mouse, you usually get transferred to a new location in the web and a new web page is opened. With JavaScript you can do something else and generate a new user experience.

As I said at the very beginning: What I am after in this post is to generalize the ideas, which are behind HTML, CSS and JavaScript. So, let's look at the figure above. The object model captures three aspects: form, style and syntax.

We call the logical model of a language (like HTML) its form. The form contains language conceptions and their relations. Together with a syntax definition, a notation, the logical model can be serialized as a stream of characters. It's a both way thing. The character stream can be transformed into a form and vice versa. In case of HTML, it's the HTML syntax, the textual form which is send as messages via HTTP.

To produce a projection, a visual representation of the form, the rendering engine processes the form and a style definition -- something like CSS, for example. That's the way, how something appears on the screen.

Events that are generated by e.g. the user and timers are digested by a processor, something like a JavaScript interpreter. The processor can modify the object model in any way. A modification has an immediate effect on the projection. The projection always presents the current "shape" of the form.

The upper part of our figures makes up what can be called editing, the lower part realizes persistence.

Just some years ago, the traditional form of writing code had a misconception (and it's still widely spread): To edit code one uses a more or less advanced text editor. If you call the structure of a programming language its form and its textual notation its syntax, it's somewhat strange why one wants to work on a serialization format and not on the form directly, benefiting from advanced projections and a powerfull I/O-model. That is where modern IDEs like Eclipse move to. Internally, Eclipse builds up a model of the code, which represents its form -- technically speaking, it is an Abstract Syntax Tree (AST). This give you cool features like automated refactoring, word completion etc. However, the actual syntax of, say, Java or C#, is too restricted and too simple, to be an suitable snapshot of the code's form. And that's a pitty. There are only very few new approaches, like Intentional Programming, which realized the limitations a today's code syntaxes.

To summarize, what we discussed here:

HTML is just a serialization format for the exchange of content that is otherwise represented in form of an object model called DOM. This serialization format is the prerequisite to send content around in HTTP messages. But the HTML format is nothing a browser works internally with. It's the object model instead.

If we apply the editing/persistence-model on programming languages, we have to conclude that programming languages are historically driven by a text-based serialization format, which is -- today -- not appropriate anymore.

Beliebte Posts aus diesem Blog

Lidl und der Kassen-Bug

Es gibt Fehler, im Informatiker-Jargon "Bugs", die etwas anrühriges haben. Ich bat den Menschen an der Kasse bei Lidl um einen Moment Geduld und meine Kinder um Ruhe, um nicht den wunderbaren Moment zu verpassen, bei dem es passierte. Der Lidl-Mensch fluchte kurz auf -- und ich war entzückt! "Einen Moment, davon muss ich ein Foto machen!" Und dann machte ich noch eines. Ich bin heute extra für diesen Fehler zu Lidl gepilgert -- ich wollte es mit eigenen Augen sehen. Gestern hat mir ein Student (vielen Dank Herr Breyer) von diesem Fehler in einer EMail berichtet. Ein richtig schöner Fehler, ein Klassiker geradezu. Ein Fehler, den man selten zu Gesicht bekommt, so einer mit Museumswert. Dafür wäre ich sogar noch weiter gereist als bis zum nächsten Lidl. Der Fehler tritt auf, wenn Sie an der Kasse Waren im Wert von 0 Euro (Null Euro) bezahlen. Dann streikt das System. Die kurze Einkaufsliste dazu: Geben Sie zwei Pfandflaschen zurück und Lidl steht mit 50 Cent bei Ihne...

Syntax und Semantik

Was ist Syntax, was ist Semantik? Diese zwei Begriffe beschäftigen mich immer wieder, siehe zum Beispiel auch " Uniform Syntax " (23. Feb. 2007). Beide Begriffe spielen eine entscheidende Rolle bei jeder Art von maschinell-verarbeitbarer Sprache. Vom Dritten im Bunde, der Pragmatik, will ich an dieser Stelle ganz absehen. Die Syntax bezieht sich auf die Form und die Struktur von Zeichen in einer Sprache, ohne auf die Bedeutung der verwendeten Zeichen in den Formen und Strukturen einzugehen. Syntaktisch korrekte Ausdrücke werden auch als "wohlgeformt" ( well-formed ) bezeichnet. Die Semantik befasst sich mit der Bedeutung syntaktisch korrekter Zeichenfolgen einer Sprache. Im Zusammenhang mit Programmiersprachen bedeutet Semantik die Beschreibung des Verhaltens, das mit einer Interpretation (Auslegung) eines syntaktisch korrekten Ausdrucks verbunden ist. [Die obigen Begriffserläuterungen sind angelehnt an das Buch von Kenneth Slonneger und Barry L. Kurtz: Formal Syn...

Factor @ Heilbronn University

It was an experiment -- and it went much better than I had imagined: I used Factor (a concatenative programming language) as the subject of study in a project week at Heilbronn University in a course called "Software Engineering of Complex Systems" (SECS). Maybe we are the first university in the world, where concatenative languages in general and Factor in specific are used and studied. Factor is the most mature concatenative programming language around. Its creator, Slava Pestov, and some few developers have done an excellent job. Why concatenative programming? Why Factor? Over the years I experimented with a lot of different languages and approaches. I ran experiments using Python, Scheme and also Prolog in my course. It turned out that I found myself mainly teaching how to program in Python, Scheme or Prolog (which still is something valuable for the students) instead of covering my main issue of concern: mastering complexity. In another approach I used XML as a tool ...