[erlang-questions] ANNOUNCE: adapter_pattern for mochiweb/cowboy/misult and scripting language
Joe Armstrong
of interest.
https://github.com/joearms/adapter_pattern
What's this all about? Mochweb, misultin and cowboy all have
*different* interfaces
I don't like this. I have made a simple generic interface to all three.
Yesterdays announcement that misultin would not be supported in the future
sparked off this work - I'd been thinking about how to abuse
paramerised modules for a while
so this seemed like a golden opportunity.
I also threw in a web scripting language called EHE. EHE is "Html with
embedded Erlang"
So <?e Name = "joe" ?> has <?e integer_to_list(Name) ?> characters
would print out "joe has 3 characters" - inside the <?e ... ?> we
expect a sequence of
Erlang expressions. The replacement value is the value of the *last*
expression in the
sequence which must be a string. Bindings are forward propagated in the script.
That's it.
Although this is *very* simple it is also very powerful (ie it has the
full power of all of erlang)
It is also very easy to embed into your favorite web server - the
example on github shows how
to embed ehe into mochiweb/misultin and cowboy.
It would seem to me to be advantageous to agree to use EHE (or
something better) on all
available erlang web-servers - since a common langage would encourage
code sharing and so on
(like PHP)
Take a look?
Is this the right way to go?
Cheers
/Joe
_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions
Edmond Begumisa
EHE reminds me of Yariv's ErlTL which I very much like...
https://github.com/yariv/erlyweb/blob/master/src/erltl/erltl.erl
http://yarivsblog.blogspot.com.au/2006/10/introducing-erltl-simple-erlang.html
http://yarivsblog.blogspot.com.au/2006/10/erltl-091.html
ErlTL has some nice features, perhaps these two could be combined.
- Edmond -
> Take a look?
>
> Is this the right way to go?
>
> Cheers
>
> /Joe
> _______________________________________________
> erlang-questions mailing list
> erlang-q...@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Richard O'Keefe
http://www.oed.com/view/Entry/86297?rskey=8Hch8X&result=1#eid
However, there are times when I strongly disagree with him,
and on this occasion at least, it's _because_ he's a sense 1
hero and I'm *not*.
On 18/02/2012, at 3:31 AM, Joe Armstrong wrote:
> I also threw in a web scripting language called EHE. EHE is "Html with
> embedded Erlang"
>
> So <?e Name = "joe" ?> has <?e integer_to_list(Name) ?> characters
FUNDAMENTAL LAW NUMBER ONE.
I make mistakes. Lots of mistakes. Lots of stupid little
mistakes. Not so many type errors, but more than enough
typing errors.
I need help.
FUNDAMENTAL LAW NUMBER TWO.
Strings don't nest.
It didn't have to be that way. Lisp embeds Lispy mini-languages
with the greatest of ease, but Lisp is fully bracketed. Algol
60 strings had distinct left and right quotation marks, so they
_did_ nest. Just try to find an "Algol 60" compiler that
supported them! If you use straight-up-and-down quotation marks
like Fortran and Smalltalk '...' or C or Java "...", they just do
not nest. HTML uses '...' and "..." in some contexts and
<![CDATA[...]]> and <!-- ... --> and <? ...> (in XHTML, <? ... ?>)
in others.
They don't nest.
STRING COROLLARY TO MURPHY'S LAW.
What *can* go wrong in a language embedded in HTML syntax *will*
go wrong. Often. Embarrassingly.
EMPIRICAL LAW NUMBER THREE.
None of the HTML or XML editing, checking, or validation tools available to
me knows anything about Erlang syntax, at least not when processing HTML
or XML, and similarly,
none of the Erlang editing, checking, or validation tools available to me
knows anything about HTML or XML, at least not when processing Erlang.
DIABOLIC COROLLARY.
With the embedded approach tool help is least available to me
when I need it most.
The diabolic corollary does *not* apply to embedding languages with *compatible*
lexical/syntactic structures. A few years ago I generated a fair bit of XML
using a Scheme toolkit I called SXS (Simple XML in Scheme, pronounced "success",
and for me it _was_ a success). However, the XML was written using Schemely
syntax.
The "native HTML" way to do it would be to write an HTML page using any HTML
editor you like, attach hook points to it using 'class' and 'id', use
<script> to attach file-specific code, and give it to process that parses
it, applies the transforms loaded by the <script>, and emits plain HTML.
Of course, if Joe is planning to offer a tool that validates *both* the HTML
(HTML5?) page *and* the embedded Erlang code, that's a completely different story.
Ulf Wiger
None of the HTML or XML editing, checking, or validation tools available to
me knows anything about Erlang syntax, at least not when processing HTML
or XML, and similarly,
none of the Erlang editing, checking, or validation tools available to me
knows anything about HTML or XML, at least not when processing Erlang.
Michael Turner
response to EHE, from someone who has yet to look at any existing
Erlang web frameworks in any detail:
I don't want to embed code to generate HTML *within* HTML, to be sent
to a browser. After all, what is HTML but just a clunky notation for
specifying DOM objects? No, I want to communicate with DOM objects in
the browser, having created them there in whatever way seems most
natural in Erlang terms.
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.
Assuming you're still with me here: If you don't care so much about
reusing existing template libraries, the best static representation of
a web page on the server side would seem to be some kind of Erlang
record specification of the target DOM document object, describing the
page-representation process tree you'd like to build if the page were
ever instantiated. That record (and subrecords within it) might
include funs; these funs would correspond to (and ultimately be
translated to) javascript on the client side.
With most other languages, you'd blanch at the idea of creating what
might (for a large web page) end up as thousands of server-side
processes just to represent each little leaf DOM object in a browser,
with the overwhelming majority of these leaves being static DOM
elements. But spawning processes in the thousands is what Erlang eats
for a light breakfast. So maybe it's not so crazy. Or anyway, not so
crazy after some sane person takes this idea and works back to what
makes sense. (Maybe somebody already did.)
And this addresses Richard's point "Diabolic Corollary" point: This
way, you just end up writing Erlang, and only Erlang, and can enjoy
full tool support.
-michael turner
[*] Yes, I'm aware of recent work on the latter, mentioned recently on the list.
Edmond Begumisa
wrote:
> The "native HTML" way to do it would be to write an HTML page using any
> HTML editor you like, attach hook points to it using 'class' and 'id',
> use
> <script> to attach file-specific code, and give it to process that parses
> it, applies the transforms loaded by the <script>, and emits plain HTML.
Hmmm...
There was a rather clever mozilla-based web-server called Jaxer that
provided this kind of "server-side DOM" web-programming style. It was
essentially Firefox without the rendering code running on Apache.
An html file on the server could have <script> tags with a special "runat"
attribute. If runat="server", then Jaxer would process the script server
side (with full access to the DOM and everything you normally get on the
client side). The webserver would then send the processed file to the
browser. The idea was that you'd use typically client-side JavaScript to
write web-server code, but I digress.
Although I can picture an Erlang web-framework working in a simlar fashion
as you describe (hoping this is in fact similar to what you're
describing), using Joe's example...
== foo.html ==
<html>
..
<script type="application/erlang" src="foo.erl" runat="server" />
..
So <span id="foo-name" /> has <span id="foo-chars" /> characters
..
</html>
== foo.erl ==
..
on_load(Html0) ->
Name = "Joe",
Html1 = dom:set_node_value(dom:get_element_by_id(Html0, "foo-name"),
Name),
dom:set_node_value(dom:get_element_by_id(Html1, "foo-chars"),
integer_to_list(Name)).
... I'll note that Jaxer never really gained traction and to my
disappointment it's developer's (Aptana) stopped working on it. Though I
personally like this style because of it's consistency with client-side
web-programming, perhaps it's too strange for most web-developers (even
though it shouldn't be) who seem to prefer the template style.
Nonetheless, I would love to see an Erlang Jaxer.
- Edmond -
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/-
Fredrik Svahn
> 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.
BR /F
[1] http://svahne.github.com/browserl/
Jakob Praher
>> 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.
Michael Turner
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
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?
-michael turner
Jakob Praher
> "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
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?
[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
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