this.views.list.control() is invoked when the list view is rendered.
When it is invoked, "that" is the object which was passed as parameter
of the render() method or otherwise an empty/default object. "that" is
the object that will be used as the Javascript context when rendering
the view.

Views would be E4X Javascript XML objects. When Helma would render
these views, it would parse them for "lookup", "if" and "for"
attributes and then evaluate them in the context of "that".

When parsing the "for" attributes, Helma would loop through the indicated object (topics) with
"for(var $topics in topics)"
and repeat the specified element (the table row) with
topics$ == topics[$topics]

When parsing the "lookup" attributes, Helma would check if a lookup
handler function exists and if so would apply it to the element's
content.

this.controls.list would be the function that is called in order to handle the request, similar to todays this.list_action.

Type operators and type annotations

Type annotations are optional.
To support strict options that require every declaration to be annotated,
*
may be used for ⊤ (the top type), e.g.
var v is *
, which is equivalent to
var v
.
Note that
*
is used differently for E4X, but its meaning as
⊤ is unambiguous in type operator and annotation right operand contexts.

In a nutshell,
is t
annotations insist on type
t
and defend against null and undefined (no more "foo has no properties" errors;
with static analysis, an error that can't be avoided at runtime can even be
reported at compile time).
as t
annotations enforce (
is t
)-or-null invariance.
And
to t
annotations convert according to cleaner,
class-extensible rules.

[...]

Given types, you can assert (is), coerce (as), or convert (to).
Conversion alone is not enough, since it either leaves null
unconverted, which is a "foo has no properties" hazard that one should
be able to assert against with an annotated declaration; or conversion
changes, e.g., null to String "null", which may be acceptable with
dynamic types only (Edition 3 and earlier), but which is wrong with
asserting and coercing annotations such as "var str is String" and "var
strOrNull as String".

Since "to" converts rather than asserts or coerces, it is not sufficient as the only kind of type annotation.

Hence the symmetry between the type operators and annotations.
Failing to provide an annotation for a type operator gratuitously
forces programmers to hand-code constraints, instead of letting the
type system do the work.

"[...] a well-known
problem with the design and use of technology, and one that is clearly
related
to Murphy's law - "Anything that can go wrong, will." (Actually, this is
Finagle's law, which in itself shows that Finagle was right.)"

In one point, oriba san's comment is certainly right:
"I can't seem to find one good information resource for javascript. it's scattered all over the web.
javascript is a mess
."
That is true, which is why I believe so strongly that we should make tabula rasa and call the paradigm shift towards modern client/server-side Javascript by its original project name:
Mocha!
That way we will know what we get when we google for information resources.

"So my earlier prediction has become true: JavaScript is gaining
popularity as an all-purpose development language. One thing's for
sure:
there are more and more JavaScript-based frameworks popping up
for all levels of application development."
Well, in the case of OpenMocha and Helma they might be "popping up"
more, but they've been around and have evolved for several years. So,
has Whitebeam. And Trimpath Junction isn't on the server-side (but
could be, using Helma). All these server-side projects' roots go back to the
1998-2000 time frame. In retrospect I must say, neither
me
nor
Hannes
did a very good job at telling people that our projects were "server-side Javascript".

"When Java started, it was easy to write web applications.
Now, to build a Java application in the lightweight way, you need to learn
servlets, XML, struts, some persistence framework like Hibernate or
iBATIS, and Spring to help glue it all together. That's an oppressive
learning curve. And three years from now, when the state of the art has
changed, you'll have to do it all again.
Java's not approachable to the
masses like it once was.
"

Your email address:
The "Decentralize" Newsletter
Exchanging ideas for building a
decentralized fabric of society.
Making true democracy work on a larger
scale while decentralizing "everything",
benefiting from local diversity and
global synergies at the same time.
http://tinyletter.com/zumbrunn