#6 Wanted: Some kind of ajax bindings

[dumlMaster]

e ask people to write asynchronous code declaratively in disparate tags.
We have lots of code like this:

<form action="something.do" onsubmit="new DumlLoader(this).execute
('someExpectedTargetId');return false;" method="post">
<button onclick="this.form.action='somethingElse.do;this.form.onsubmit
();return false;">Do Something Else</button>
<button type="SUBMIT">Do The Normal Something</button>

As it turns out this is not only really complicated because developers
have to know a lot, but actually just repetitive and confusing. They have
to know how forms and submit and onsubmit work in how events are canceled
and how closures are created -- what kinds of actions do and don't fire
them events, they have to know how to reuse or throttle DumlLoaders, etc.
To accomplish almost anything beyond the simplest of ideas - we see people
creating named functions and calling those. Now they also wind up
seperating this in the code which has the upshot of seperating the DUML
bits out, but has the downside of leaving readers clueless and creating a
problem of when and where to include the script file, etc.

All applications are singletons and all functions are also data - so when
you want to create a reusable DumlLoader, for example, you say:

var myDL = new DumlLoader( frm );

If we look at it this way - essentially it's all pattern based, which
means that we can factor out the bulk of it and just make it configuration
based. This creates a situation where we can take care of the majority of
the complexity (even in the current model) by allowing _some_ tag to
express things like the named AJAX configuration (which might be DUML) and
then just allowing ways to attach events or things to it via some kind of
binding mechanism.

As to what tag -- could be executeScript like the API calls - that's very
easy -- could be properties, a little harder, but perhaps more intuitive --
could be a new tag)

In fact this is part of a larger problem that we should not ignore in
solving this problem which is bindings in general... Currently components
are in terms of user code (tags), attached to other tags, events of other
tags or even data with singularly oriented attachTo attributes. This is
pretty convient in a lot of cases, but there are actually considerably
more cases where we want to accomplish the same things internally, or want
to allow users (or even ourselves internally) to more easily express these
kinds of relationships. Having a nice clean model for doing this would be
really helpful in a whole lot of ways.