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

[Jakob Praher]

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