[erlang-questions] ANNOUNCE: adapter_pattern for mochiweb/cowboy/misult and scripting language

[Michael Turner]

"I am a big fan of Alan and his viewpoints ;-). Still at the core [1]
the DOM is a recursive tree data structure (with destructive
updates)."

The source you cite doesn't go quite that far. In fact, it's
explicitly *not* committing to a data representation.

"Most of the APIs defined by this specification are interfaces rather
than classes. That means that an implementation need only expose
methods with the defined names and specified operation, not implement
classes that correspond directly to the interfaces. This allows the
DOM APIs to be implemented as a thin veneer on top of legacy
applications with their own data structures, or on top of newer
applications with different class hierarchies. [...] The DOM Level 2
API does not define a standard way to create DOMImplementation
objects; DOM implementations must provide some proprietary way of
bootstrapping these DOM interfaces, and then all other objects can be
built from there."

(Note that "method" comes originally from Smalltalk, Smalltalk comes
originally from Alan Kay, and Alan Kay thought more in terms of
"messages" to objects. Note also that they speak of "data structures"
in the case of "legacy applications", but only of "class hierarchies"
in the case of "newer applications."  A class hierarchy doesn't have
to specify classes of data structures.)

So: if someone were to write a browser in Erlang in which all DOM
elements were represented as processes, I'd expect the architects of
DOM to shrug and say, "It's basically compliant with the standard if
Javascript works. As for your implementation style... well, whatever
floats your boat."

"A browser thus is a typical instance of the model view pattern."

I'd write this as "Given that a *typical* browser takes the view of
DOM as a tree with destructive updates, it typically implements the
model-view pattern." Likewise for the server side, if your web app
represented model *and* view as a tree of DOM proxy objects, with each
object an Erlang process.

It might be a dumb way to do it (as I said, anybody taking up this
everything-a-process idea should work back from its extremism to
whatever makes sense), but it could still be a standards-compliant
implementation.

-michael turner

On Wed, Feb 22, 2012 at 7:22 AM, Jakob Praher <jakob@REDACTED> wrote:
> Am 21.02.12 03:32, schrieb Michael Turner:
>> "IMHO a DOM object is a data structure (term) ..."
>>
>> But in the browser, a DOM object represents something that's
>> *happening*, even if what's "happening" appears to us as a static
>> display in a browser window. When you delve into what's happening in
>> the hardware in order to make the right photons spray out toward your
>> retina from any given point, you find out there's a lot going on. You
>> can tell the DOM object to make something different happen, just by
>> changing the values in it. Ontologically, that makes it a process. And
>> (I would say) an object in Alan Kay's original sense:
>>
>>  http://erlang.2086793.n4.nabble.com/Erlang-quot-object-oriented-quot-after-all-td2101240.html
> I am a big fan of Alan and his viewpoints ;-). Still at the core [1] the
> DOM is a recursive tree data structure (with destructive updates). A
> browser thus is a typical instance of the model view pattern. In the
> browser the view is the rendering engine (the thing that produces what
> the users sees from a document). Yet this rendering is hand optimized
> C++ code which is not very extensible - aside script code that renders
> the <canvas> element, which still feels like a second class citizen also
> due to design issues (does not integrate good with the rest of the
> rendering process) and security restrictions [2].
>> So why not represent the state of that object as the arguments to a
>> tail-recursive function that waits for messages and sends messages? At
>> least as a first cut?
>>
>> "... therefore I would be more interested in composable abstraction
>> over these terms, much like a parser abstracts over concrete syntax."
>>
>> I understand the appeal of that, but ... parsers have the luxury of
>> chomping through a meal that sits still. You can make rules about how
>> morsels should be arranged on the plate. As soon as you go dynamic,
>> you've got things crawling around on your plate -- possibly capable of
>> reproduction as well. You're sending programs, and programs can write
>> programs. You're back to how we compose "abstractions" in
>> Turning-complete programming languages, and your composability is
>> defined by little more than the grammar of the language -- which can't
>> really tell you much about what's happening when a program runs, or
>> else we'd have algorithms that solve the Halting Problem.
>>
>> Anyway, if you want the ultimate in composable abstraction for the
>> web, something "much like a grammar," don't you end up back at
>> XML/XSLT?
> Parsers not strictly in the grammar sense, but as monadic objects/actors
> [3] that also capture side effects like user interaction. Regarding
> XSLT: Also in these modern HTML5 apps that manipulate the DOM via
> Javascript you end up having templating systems typically wrapped inside
> <script> elements bodies (e.g. mustache) which ressembles XSLT
> templates. From the abstraction point of view this is the same thing as
> XSLT.
>
> There is an improvement in abstraction - e.g. if one thinks of JQuery
> like widgets - but this does not feel like a natural thing to do - one
> easily breaks abstraction by depending on the context too much - e.g.
> using $() to select an outer element and using the document object feels
> like a singleton in OO).
>
> - Jakob
>
> [1] - http://www.w3.org/TR/DOM-Level-2-Core/core.html
> [2] -
> https://developer.mozilla.org/en/HTML/Canvas/Drawing_DOM_objects_into_a_canvas
> [3] - http://gbracha.blogspot.com/2011/01/maybe-monads-might-not-matter.html
>>
>> -michael turner
>>
>>
>> On Tue, Feb 21, 2012 at 5:48 AM, Jakob Praher <jakob@REDACTED> wrote:
>>> Am 20.02.12 19:51, schrieb Fredrik Svahn:
>>>>> To me, the most natural Erlang representation of a DOM object is the
>>>>> same as for any "object": it's an Erlang process. Now, I can't have an
>>>>> Erlang process in the browser itself (unless someone writes a web
>>>>> browser in Erlang, or implements Erlang in the browser[*]). But I
>>>>> *can* have Erlang processes on the server side, to interrogate and
>>>>> update page state as if its corresponding DOM objects were all Erlang
>>>>> processes.
>>>> Actually, in the version of browserl[1] I checked in a week ago, a DOM
>>>> object is a (pseudo-)process. At one point it was even possible to
>>>> send messages to it (e.g. to request an update) but that doesn't work
>>>> any longer. I might revisit the idea later if/when I get the time.
>>> IMHO a DOM object is a data structure (term) therefore I would be more
>>> interested in composable abstraction over these terms, much like a
>>> parser abstracts over concrete syntax.
>>>
>>> But if we are at it: How would you model a browser, if you could write
>>> it in Erlang?  To me a browser could be described as a hierarchical term
>>> storage process (the document) plus a render process that creates
>>> controls owned by the window. Terms are updated through the storage and
>>> it is the rendering process that presents the udpates to the user.
>>> Controls would be process nodes under the window that again change terms
>>> in the storage. Only the owning window is allowed to access the term
>>> storage, making it possible to have mulitple windows with private term
>>> storages.
>>>
>>> The term storage process could even be a protected distributed process
>>> that can be shared between the client and server side. If the server
>>> sends passes mutating messages to the storage process, the client can
>>> directly reflect these.
>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-questions
>